"에 대한 후속 조치로 인덱스 란 무엇이며이를 사용하여 데이터베이스에서 쿼리를 최적화하려면 어떻게해야합니까? "에 에 대해 배우려는 경우 어떤 열이 좋은 인덱스 후보입니까? 특히 MS SQL 데이터베이스의 경우?
인터넷 검색을 한 후 내가 읽은 모든 내용은 일반적으로 증가하고 고유 한 열이 좋은 인덱스 (MySQL의 auto_increment와 같은 것)를 만든다는 것을 암시합니다.이를 이해하지만 MS SQL을 사용하고 있으며 기본 키에 GUID를 사용하고 있습니다. 인덱스는 GUID 열에 도움이되지 않습니다.
답변:
인덱스는 쿼리 최적화 및 테이블에서 신속하게 결과를 검색하는 데 중요한 역할을 할 수 있습니다. 따라서 인덱싱 할 열을 선택하는 것이 가장 중요한 단계입니다. 인덱싱을 고려할 수있는 두 가지 주요 위치가 있습니다. WHERE 절에서 참조되는 열과 JOIN 절에서 사용되는 열입니다. 요컨대, 이러한 열은 특정 레코드를 검색하는 데 필요한 인덱싱되어야합니다. SELECT 쿼리가 아래와 같은 인덱스를 사용하는 buyers라는 테이블이 있다고 가정합니다.
SELECT
buyer_id /* no need to index */
FROM buyers
WHERE first_name='Tariq' /* consider to use index */
AND last_name='Iqbal' /* consider to use index */"buyer_id"는 SELECT 부분에서 참조되므로 MySQL은 선택한 행을 제한하는 데 사용하지 않습니다. 따라서 색인을 생성 할 필요가 없습니다. 아래는 위와 약간 다른 또 다른 예입니다.
SELECT
buyers.buyer_id, /* no need to index */
country.name /* no need to index */
FROM buyers LEFT JOIN country
ON buyers.country_id=country.country_id /* consider to use index */
WHERE
first_name='Tariq' /* consider to use index */
AND
last_name='Iqbal' /* consider to use index */위의 first_name 쿼리에 따르면 last_name 열은 WHERE 절에있는 그대로 인덱싱 할 수 있습니다. 또한 JOIN 절에 있으므로 country 테이블의 추가 필드 country_id를 인덱싱 할 수 있습니다. 따라서 인덱싱은 WHERE 절 또는 JOIN 절의 모든 필드에서 고려할 수 있습니다.
다음 목록은 테이블에 인덱스를 만들 때 항상 염두에 두어야 할 몇 가지 팁을 제공합니다.
업데이트 (2015 년 2 월 23 일) :
모든 인덱스 (양호 / 불량)는 삽입 및 업데이트 시간을 증가시킵니다.
인덱스 (인덱스 수 및 유형)에 따라 결과가 검색됩니다. 색인으로 인해 검색 시간이 증가한다면 그것은 잘못된 색인입니다.
모든 책에서 "색인 페이지"는 장 시작 페이지, 주제 페이지 번호 시작, 하위 주제 페이지 시작을 가질 수 있습니다. 색인 페이지의 일부 설명이 도움이되지만 더 자세한 색인은 혼란 스럽거나 겁을 줄 수 있습니다. 인덱스에도 메모리가 있습니다.
인덱스 선택은 현명해야합니다. 모든 열에 색인이 필요한 것은 아닙니다.
WHERE, JOINS또는 HAVING?
WHERE절 에서 열이 두 개의 값만 가질 수있는 필드의 값을 확인하는 경우 해당 이진 열을 인덱싱해야합니까? 이것은 잘못된 것 같습니다.
일부 사람들은 여기에서 비슷한 질문에 답했습니다. 좋은 인덱스가 무엇인지 어떻게 알 수 있습니까?
기본적으로 데이터를 쿼리하는 방법에 따라 다릅니다. 쿼리와 관련된 데이터 세트의 작은 하위 집합을 빠르게 식별하는 색인이 필요합니다. 날짜 스탬프로 쿼리하지 않는 경우 대부분 고유 한 경우에도 인덱스가 필요하지 않습니다. 특정 날짜 범위에서 발생한 이벤트를 얻는 것뿐이라면 확실히 원합니다. 대부분의 경우 성별에 대한 지표는 무의미합니다.하지만 모든 남성에 대한 통계를 얻고 별도로 모든 여성에 대한 통계를 얻는다면 시간을내는 것이 가치가있을 수 있습니다. 쿼리 패턴이 무엇인지 파악하고 어떤 매개 변수에 액세스하여 검색 공간을 가장 많이 좁 히면 이것이 최상의 인덱스입니다.
또한 만드는 인덱스의 종류를 고려하십시오. B- 트리는 대부분의 작업에 적합하고 범위 쿼리를 허용하지만 해시 인덱스는 요점을 바로 알려줍니다 (하지만 범위는 허용하지 않음). 다른 유형의 인덱스에는 다른 장단점이 있습니다.
행운을 빕니다!
그것은 모두 테이블에 대해 어떤 쿼리를 기대하는지에 달려 있습니다. 열 X에 대해 특정 값을 가진 모든 행을 요청하면 인덱스를 사용할 수없는 경우 전체 테이블 스캔을 수행해야합니다.
인덱스는 다음과 같은 경우에 유용합니다.
다음과 같은 경우에는 유용하지 않습니다.
기본 키 열은 고유하고 행을 조회하는 데 자주 사용되기 때문에 일반적으로 인덱싱에 적합합니다.
일반적으로 (나는 mssql을 사용하지 않으므로 특별히 주석을 달 수 없습니다) 기본 키는 좋은 인덱스를 만듭니다. 고유하며 값을 지정해야합니다. (또한 기본 키는 일반적으로 인덱스가 자동으로 생성되는 좋은 인덱스를 만듭니다.)
인덱스는 사실상 이진 검색을 허용하도록 정렬 된 열의 복사본입니다 (선형 검색보다 훨씬 빠름). 데이터베이스 시스템은 특히 데이터가 단순한 숫자보다 복잡한 경우 검색 속도를 높이기 위해 다양한 트릭을 사용할 수 있습니다.
내 제안은 처음에 색인을 사용하지 않고 쿼리를 프로파일 링하는 것입니다. 특정 쿼리 (예 : 성을 기준으로 사람 검색)가 자주 실행되는 경우 관련 속성 및 프로필에 대한 색인을 다시 만들어보십시오. 쿼리 속도가 눈에 띄게 증가하고 삽입 및 업데이트 속도가 무시할 정도로 느려진다면 인덱스를 유지하십시오.
(다른 질문에서 언급 한 내용을 반복하는 경우 죄송합니다. 이전에 본 적이 없습니다.)
테이블에서 데이터를 추출하는 데 정기적으로 사용되는 열은 인덱싱되어야합니다.
여기에는 다음이 포함됩니다. 외래 키-
select * from tblOrder where status_id=:v_outstanding설명 필드-
select * from tblCust where Surname like "O'Brian%"열은 고유하지 않아도됩니다. 사실 예외를 검색 할 때 바이너리 인덱스에서 정말 좋은 성능을 얻을 수 있습니다.
select * from tblOrder where paidYN='N'GUID 열은 인덱싱에 가장 적합한 후보가 아닙니다. 인덱스는 의미있는 순서, 즉 정렬 (정수, 날짜 등)이 제공 될 수있는 데이터 유형의 열에 가장 적합합니다.
열의 데이터가 일반적으로 증가하는지 여부는 중요하지 않습니다. 열에 인덱스를 생성하면 인덱스는 저장된 순서 (비 클러스터형 인덱스)에 관계없이 테이블의 실제 항목을 참조하는 자체 데이터 구조를 생성합니다. 예를 들어 인덱스 데이터 구조에 대해 이진 검색을 수행하여 빠른 검색을 제공 할 수 있습니다.
데이터를 물리적으로 재정렬하는 "클러스터형 인덱스"를 만들 수도 있습니다. 그러나 테이블 당 하나만 가질 수 있지만 클러스터되지 않은 인덱스는 여러 개있을 수 있습니다.
오름차순 또는 내림차순으로 정렬 된 숫자 데이터 유형은 여러 가지 이유로 좋은 인덱스입니다. 첫째, 숫자는 일반적으로 문자열 (varchar, char, nvarchar 등)보다 평가하는 것이 더 빠릅니다. 둘째, 값이 정렬되지 않은 경우 색인을 업데이트하기 위해 행 및 / 또는 페이지를 섞어 야 할 수 있습니다. 이는 추가 오버 헤드입니다.
SQL Server 2005를 사용하고 고유 식별자 (guid)를 사용하도록 설정하고 임의의 특성이 필요하지 않은 경우 순차 고유 식별자 유형을 확인하세요.
마지막으로 클러스터형 인덱스에 대해 이야기하는 경우 물리적 데이터의 종류에 대해 이야기하고 있습니다. 클러스터형 인덱스로 문자열이 있으면 추악해질 수 있습니다.