답변:
처음부터 또는 성능 문제가 발생했을 때 바로 색인 생성을 시작해야합니까?
사용 패턴이 등장함에 따라 인덱싱 전략이 발전하는 경향이 있습니다. 즉, 사전에 적용 할 수있는 전략 및 설계 지침도 있습니다.
좋은 클러스터링 키를 선택하십시오 . 일반적으로 테이블에 예상되는 삽입 패턴을 기반으로 디자인 타임에 적절한 클러스터형 인덱스를 결정할 수 있습니다. 미래의 변화에 대한 설득력있는 사건이 발생한다면, 그렇게하십시오.
기본 및 기타 고유 제한 조건을 작성하십시오 . 이들은 고유 인덱스에 의해 시행됩니다.
외래 키 및 관련 비 클러스터형 인덱스를 만듭니다. 외래 키는 가장 자주 참조되는 조인 열이므로 처음부터 색인화하십시오.
매우 선택적인 쿼리에 대한 인덱스를 만듭니다 . 이미 알고있는 쿼리 패턴의 경우 선택성이 높으며 스캔보다는 조회를 사용할 가능성이 높습니다.
위의 내용 외에도 새로운 인덱스를 구현하기위한 점진적이고 전체적인 접근 방식을 취하십시오. 전체적으로, 나는 추가를 평가할 때 모든 쿼리와 기존 인덱스에 대한 잠재적 이점과 영향을 평가합니다.
누락 된 인덱스 DMV 및 SSMS 힌트의 지침으로 인해 SQL Server 서클에서 드문 일이 아닌 문제는 오버 인덱싱입니다. 이러한 도구 중 어느 것도 기존 인덱스를 평가하지 않으며 기존 5 컬럼 인덱스에 단일 컬럼을 추가하는 대신 6 컬럼 인덱스를 새로 작성하도록 제안합니다.
-- If you have this
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
)
-- But your query would benefit from the addition of a column
CREATE NONCLUSTERED INDEX [IX_MyTable_MyIndex] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)
-- SSMS will suggest you create this instead
CREATE NONCLUSTERED INDEX [IX_MyTable_AnotherIndexWithTheSameColumnsAsTheExistingIndexPlusCol6] ON [dbo].[MyTable]
(
[col1] ASC
, [col2] ASC
, [col3] ASC
, [col4] ASC
, [col5] ASC
, [col6] ASC
)Kimberly Tripp 은 인덱싱 전략에 대한 훌륭한 자료를 가지고 있으며 SQL에 중점을 둔 다른 플랫폼에도 적용 할 수 있습니다. SQL Server 사용자 의 경우 위의 예와 같이 중복을 식별하는 편리한 도구가 있습니다.
쿼리를 실행하는 동안 임시 인덱스를 만들 수도 있습니다. 그러한 기술의 장단점은 무엇입니까?
일반적으로 거의 실행되지 않는 쿼리 (일반적으로 ETL)에만 적용됩니다. 다음을 평가해야합니다.
두 가지 접근 방식과 관련하여 실제로 위험이 있습니다.
옵션 a) 처음부터 색인을 작성했지만 결코 사용되지 않은 많은 색인을 작성했음을 인식하지 못합니다. 이것들은 약간의 오버 헤드를 추가합니다 (데이터를 수정하는 쿼리에 가장 눈에 띄는 것이지만 최상의 인덱스를 식별하려고하는 SELECT 문의 최적화).
더 이상 사용되지 않는 인덱스를 식별하고 인덱스를 제거하려고 시도하도록 스스로 훈련해야합니다 (PostgreSQL이이를 수행 할 수 있습니다. 불행히도 MySQL은 비교할 때 매우 약합니다).
옵션 b) 사람들이 불평하기 시작하거나 진단 도구가 특정 쿼리가 느리고 개선 될 수 있다고 트리거 할 때까지 색인을 추가하지 마십시오.
당신이 소개하는 위험은 인덱스가 필요할 때와 추가해야 할 시점 사이에 시간이 충분하지 않다는 것입니다.
PostgreSQL은 인덱스 생성을 지원하므로이 CONCURRENTLY갑작스러운 인덱스 추가 요구 사항으로 인한 스트레스의 일부를 줄이지 만 매뉴얼 에는 몇 가지주의 사항 이 있습니다.
옵션 (b)는 내가 선호하는 경향이 있지만 두 옵션의 하이브리드가 최선의 해결책이라고 생각합니다. 지수가 실제로 사용될 것이라고 생각하는지 여부는 신뢰 수준과 관련이 있습니다.
이것을 특히 복잡한 토론으로 만드는 것은 일반적으로 인덱스를 변경하기 쉽지만 스키마를 변경하기는 어렵다는 것입니다. 나는 b 의 지연된 반응 을 무모한 변명으로 홍보하고 싶지 않다 .
몇 가지만 추가하면됩니다.
이것이 나의 접근법이다.
넣어 두려워하지 마십시오 > 0또는 > ""사용하지 않는 컬럼에 대한 어디에 절을한다.
select * from blah
where A="one"
and B="two"
and C>="" --to match index
and D="four"
--This will use your existing index. No need to create a redundant one.