SQL Server에서 큰 테이블을 인덱싱

Question

큰 테이블 (1 천만 개 이상의 레코드)이 있습니다. 이 테이블은 응용 프로그램의 검색에 많이 사용됩니다. 그래서 테이블에 인덱스를 만들어야했습니다. 그러나 테이블에 레코드를 삽입하거나 업데이트 할 때 성능이 저하됩니다. 인덱스를 다시 계산할 가능성이 큽니다.

개선 방법이 있습니까?

미리 감사드립니다.

Answer 1

인덱스의 채우기 비율을 줄여 페이지 분할 수를 줄일 수 있습니다. 기본적으로 채우기 비율은 0입니다 (100 %와 동일). 따라서 색인을 다시 작성할 때 페이지가 완전히 채워집니다. 이것은 수정되지 않은 테이블 (삽입/업데이트/삭제)에 유용합니다. 그러나 데이터가 수정되면 인덱스를 변경해야합니다. Fill Factor가 0이면 페이지 분할이 보장됩니다.

채우기 비율을 수정하면 페이지가 항상 분할되지 않아 삽입 및 업데이트 성능이 향상됩니다. Fill Factor = 90으로 인덱스를 다시 작성하는 것이 좋습니다. 이렇게하면 페이지의 10 %가 비어있게되어 페이지 분할이 줄어들고 I/O가 줄어 듭니다.90이 사용하기에 최적의 가치가 아니기 때문에 여기에 '시행 착오'가있을 수 있습니다.

채우기 비율에 다른 값을 사용하면 선택 쿼리가 약간 느려질 수 있지만 채우기 비율이 90 %이면 너무 많이 눈치 채지 못할 것입니다.

Answer 2

색인을 볼 필요는 있지만 그렇습니다.

명심해야 할 점은 일반적으로 모든 열에 인덱스를 넣고 싶지는 않으며 일반적으로 인덱스 당 하나의 열만 있으면 안된다는 것입니다.

실제 검색을 기록하고 사용자가 실제로 검색 한 내용을 추적하고 해당 검색 유형을 대상으로 색인을 생성 할 수 있다면 가장 좋은 방법입니다.

Answer 3

이 고전 엔지니어링 트레이드 오프가 ... 당신은 삽 밝거나 강하게 만들 수있다, 결코 모두 (재료 과학 분야에서 획기적인 때까지.)

더 많은 인덱스 더 DML 유지 보수를 의미 수단 빠른 쿼리.

인덱스가 적을수록 DML 유지 관리가 적어 질수록 쿼리 속도가 느려집니다.

색인 중 일부가 중복되어 결합 될 수 있습니다.

Joel이 작성한 것 외에 DML 용 SLA도 정의해야합니다. 괜찮습니까? 느린 것 같습니다. 속도가 느려진다는 것을 알았지 만 달성 한 쿼리 개선 대 정말 중요합니다 ... IOW, 약한 가벼운 삽을 가지고 있으면 괜찮습니까?

Answer 4

솔루션의 숫자는 당신이 선택할 수 있습니다

a) 귀하는 분할 할 수있는 테이블

B) 밤처럼 (offpeak 시간에 일괄 업데이트를 수행 고려)

C) 이후 엔지니어링은 균형을 이루는 균형 잡힌 동작이므로 어떤 것이 더 중요한지 (선택/업데이트/삽입/삭제)와 어떤 작업이 더 중요한지 선택해야합니다. 당신이 "삽입"를 실시간으로 결과를 필요로하지 않는 가정하면, 당신은 "덜 중요한"작업을 비동기 적으로

http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx

감사를 수행하는 작업에 대한 SQL Server 서비스 브로커를 사용할 수 있습니다 -RVZ

Answer 5

클러스터 된 인덱스가 ID 숫자 필드에없는 경우 페이지를 다시 정렬하면 속도가 느려질 수 있습니다. 이 경우 클러스터되지 않은 인덱스 (인덱스가없는 것보다 빠르지 만 클러스터 된 인덱스보다 약간 느려지므로 선택 항목이 느려지지만 삽입 기능이 향상 될 수 있음)으로 속도를 향상시킬 수 있는지 확인하십시오.

사용자가 느리게 삽입하거나 더 느린 선택으로 업데이트하는 것을 더 용납 할 수있는 것으로 나타났습니다. 그것은 일반적 규칙이지만 허용 할 수 없을 정도로 느린 경우 (또는 시간이 초과 될 때) 아무도 그 우물을 처리 할 수 ​​없습니다.