SqlServer 인덱스 자동 최적화 도구

일손 이 심각하게 부족 한 것 을 감안 하여 하나하나 라 이브 러 리 를 수 동 으로 고 칠 생각 을 단념 하 였 다.현재 의 프로그램 구 조 는 혁명 을 하 는 방법 을 허락 하지 않 고 개량 만 할 수 있 기 때문에 자동화 도 구 를 만들어 처리 하려 고 한다.원형 이 개발 되 자마자 회의 때 꺼 내 자마자 운영 DBA 팀 의 강력 한 저항 을 받 았 고 구체 적 인 원인 은 알려 지지 않 았 다.마지막 으로 무기한 연기 하 다.여기 서 생각 을 나 누 어 라.벽돌 을 찍 는 것 을 환영 합 니 다.전체적인 사고방식 은 이렇다.색인 은 검색 과 업 데 이 트 를 위 한 것 이지 만 적합 하지 않 은 색인 은 삽입 과 업데이트 에 부정적인 영향 을 미친다.표 에 있 는 기 존의 색인 에 대해 그것 을 식별 하 는 것 은 효과 적 이 고 불가능 하 다.그럼 기 존 데이터 사용 상황 에 따라 모든 새로운 색인 을 재 구축 하면 해결 되 잖 아.검색 에 따라 새로운 색인 을 만 든 다음 기 존 과 비교 하여 일치 하지 않 는 모든 것 을 삭제 합 니 다.원래 만 들 지 않 았 던 것 입 니 다.운영 중인 시스템 에 위험 이 크다 고 는 하지만근 데 임계 테스트 는 할 수 있 잖 아.구체 적 인 해결 방안 은 다음 과 같다.먼저 열 비 된 데이터베이스 서버 에서 정기 적 으로 캐 시 를 캡 처 하 는 실행 계획(SQL 을 캡 처 하려 고 했 는데 일부 SQL 이 너무 섞 여 있어 자동화 해석 가능성 이 없 음)을 발견 한 다음 에 이 실행 횟수 즉 표 의 통계 메시지 와 함께 예비 서버 의 데이터 시트 에 다운 된다.계획 을 몇 번 쌓 은 후에 해석 을 시작 합 니 다.실행 계획 은 형식 이 좋 은 XML 파일 이 고 마이크로소프트 가 실행 계획 을 제공 하 는 XSD 파일 이기 때문이다.우 리 는 각 노드 에 대응 하 는 SQL 서술 어 를 역방향 으로 내 놓 을 수 있다.예 를 들 어 색인 을 만 드 는 데 우 리 는 세 가지 서술 어 에 관심 이 있 습 니 다.각각 Select,Join,Where 입 니 다.이것 만 받 으 면 우 리 는 좋 은 색인 을 만 들 수 있다.원 리 는 간단 합 니 다.Join 과 Where 는 모두 색인 키 의 근거 이 며,Select 는 Index 의 Include 에 추가 할 수 있 습 니 다.해석 할 때 도 하나의 실행 계획 이 아니 라 모든 실행 계획 을 모두 분해 한 후 통계 처리 하 는 것 이다.좋 은 점 은 표 필드 가 가장 많이 인용 되 었 다 는 것 을 알 수 있다 는 것 이다.그것 은 외 키 열 이다.그 데이터 들 은 반복 적 으로 조회 되 었 다.예 를 들 어 태 블 릿 A 를 알 수 있 는 콜 1 열 은 하루 업무 과정 에서 10W 회,Where2W 회 에 가입 되 었 다.콜 2 는 셀 렉 트 10W 번,위 치 는 100 번 에 불과 했다.이렇게 해서 우리 가 색인 을 만 드 는 기 초 는 표 에 기반 한 것 이지 단일 조회 에 기반 한 것 이 아니다.최종 적 으로 생 성 된 Index 는 조회 빈도 와 조회 의 중요성 을 저울질 할 것 입 니 다.만약 에 특정한 업무 조회 가 특히 중요 하지만 실행 빈도 가 높 지 않 으 면 저 희 는 가중치 를 제공 하고 색인 을 우선 만 들 수 있 습 니 다.물론 Index 를 만 들 려 면 표 의 데이터 분 포 를 참고 하여 Index 필드 의 순 서 를 결정 해 야 합 니 다.자,준비 작업 이 끝나 면 색인 을 만 들 기 시작 합 니 다.현재 가지 고 있 는 조건,표 데이터 분포,표 필드 는 각각 참조 횟수(Select,Join,Where)와 이 SQL 서술 어 들 이 나타 나 는 횟수 를 조회 합 니 다.색인 을 만 드 는 방법 에 대한 생각 은 하나하나 분석 하고 모든 가능성 을 고려 해 만 드 는 것 이다.이런 방식 은 사람의 뇌 에 만 적합 하고 컴퓨터 가 먼저 컴퓨터 의 아 이 큐 를 120 이상으로 늘 려 야 타당 성 이 있다 는 것 을 발견 했다.역방향 사 고 를 발견 하 는 데 도 큰 도움 이 된다.한꺼번에 가장 적합 한 것 을 만 들 수 없 으 면 우 리 는 계획 을 실행 한 조합 에 따라 모든 Index 조합 을 만 들 겠 다.Join 과 Where 는 모두 Index 의 Key 에 넣 습 니 다.예 를 들 어 select t1.A,t1.B,t1.C,t2.J,t2.k from Table 1 t1 Join Table 1 t2 on t1.A=t2.j Where t1.A='param'이 만 든 색인 은 Index(A,B)include(C)와 Index(j)include(j,k)에 관 한 Select 가 작은 데이터 형식 이 라면 Alter 의 실행 계획 에서 이 데이터 수정 빈 도 는 아주 작은 것 을 Include 에 넣 습 니 다.빅 데이터 형식 과 수정 이 잦 은 것 은 그만 두 세 요.이렇게 해서 우 리 는 서로 덮 인 것 을 제거한다.부분 이 겹 치고 부분 이 겹 치 는 것 은 그 참고 집행 빈도 와 조회 의 중요성 을 유지 하 는 것 이다.차이 가 매우 작은 것 은 하나 로 합 쳐 집 니 다.예 를 들 어 1.Index(A,B,C)Include(D)2.Index(A,B,D)Include(C)는 Index(A,B)Include(C,D)로 직접 합 쳐 집 니 다.물론 Alert 가 특히 적 으 면 Index(A,B,C,D)로 합 칠 수 있 습 니 다.이것 은 C,D 필드 의 수정 빈 도 를 참고 하 십시오.홈 키 와 겹 치 는 제거.이렇게 남 긴 것 은 기본적으로 우리 가 필요 로 하 는 색인 이다.기 존 색인 을 비교 하여 덮어 쓰 는 과정 은 생략 합 니 다.간단하게 Create Index 를 끌 어 내 서 해석 처리 하면 됩 니 다.발표 할 때 간단 해.스 크 립 트 를 써 서 업무 가 적 을 때 Drop 과 Create 를 하면 됩 니 다.프로젝트 소스 코드 는 회사 의 비밀 유지 문제 로 인해 올 리 지 않 습 니 다.간단 한 조 회 를 위 한 SQL 실행 계획 캐 시 는 짧 고 캐 시가 부족 하면 삭 제 됩 니 다.이 SQL 의 실행 주파수 오차 에 주의해 야 합 니 다.Sqlserver R2 XSD:http://schemas.microsoft.com/sqlserver/2004/07/showplan/sql2008/showplanxml.xsd총 결 된 노드 맵 은 다음 과 같 습 니 다.sql 실행 계획 을 조회 하 는 것 은 노드'StmtSimple'에 포함 되 어 있 습 니 다.이 노드 가 없 으 면 보통 다른 유형의 SQL 실행 계획 입 니 다.Join 과 관련 된 노드 는 자신의 유형 과 관련 이 있 습 니 다.보통 Hash,Marger 에 포함 되 어 있 습 니 다.Join 이 Where 조건 이면 SeekKey 와 Compare 노드 에 나타 납 니 다.Join 의 열 이 쌍 을 이 루어 나타 나 기 때문에 여기 서 쉽게 식별 할 수 있 습 니 다.하 나 는 매개 변수(@시작)나 상수(type="Const")는 반드시 Where 조건 입 니 다.Select 최종 출력 필드 를 쉽게 찾 을 수 있 습 니 다.첫 번 째 Output List 노드 는 바로...주의해 야 할 것 은 일반 열 에 있 는 모든 ColumnReference 는 라 이브 러 리 이름,표 이름,열 정 보 를 포함 하지만 시스템 표 는 그렇지 않 기 때 문 입 니 다.제거 에 주의 하 다.