나는 매년로드되는 고정 길이 플랫 파일의 구성을 반영하는 단일 대형 비정규 화 테이블을 가지고 있습니다. 112 개의 열과 400,000 개의 레코드가 있습니다. 이 테이블에 대해 가장 많이 실행되는 쿼리의 where 절을 구성하는 3 개의 열에 고유 한 클러스터 된 인덱스가 있습니다. 색인 Frag는 .01입니다. 쿼리 성능이 1 초 미만입니다. 그러나 모든 레코드를 반환하는 데는 거의 2 분이 걸립니다. 실행 계획에 따르면 비용의 100 %가 클러스터 된 인덱스 스캔 (탐색이 아님)에 있음을 나타냅니다.대형 비정규 화 테이블 최적화
가입을 요구하는 쿼리 (denorm 때문에)가 없습니다. 이 테이블은보고에 사용됩니다. 모든 필드는 nvarchar 유형입니다 (데이터 파일의 필드 길이).
표 정규화를 넘어. 성능 향상을 위해 무엇을 할 수 있습니까?
쿼리의 페이지 매김을 시도하십시오. 결과를 100 개의 행 그룹으로 나눌 수 있습니다. 그러면 사용자가 결과를 매우 빨리 볼 수 있습니다. 또한 결과를 볼 때마다 모든 데이터를 볼 필요가 없으면 검색된 데이터의 양을 크게 줄일 수 있습니다.
이외에도 데이터를 필터링하는 쿼리에 매개 변수를 추가하면 반환되는 데이터 양이 줄어 듭니다.
SQL Pagination Query with order by 그냥 페이지 변수를 사용하여 대답에서 "50"및 "100"를 교체하고 당신은 갈 수 있어요 :
이 포스팅은 좋은 방법은 페이지 매김을 시작하는 것입니다.
다음은 세 가지 아이디어입니다. 먼저 nvarchar가 필요하지 않은 경우이 값을 varchar로 전환합니다. 저장 요구 사항이 절반으로 줄어들고 작업 속도가 빨라집니다.
둘째, 필드 길이가 nvarchar (4000)/varchar (8000)보다 작아야합니다. 값이 커지면 값이 별도의 페이지에 저장되어 검색 시간이 길어집니다.
셋째, 데이터를 검색하는 방법을 말하지 않습니다. Excel 또는 ODBC와 같은 다른 도구로 다시 가져 오는 경우 다른 성능 병목 현상이있을 수 있습니다.
그러나 많은 양의 데이터를 검색 중이므로 소수의 행을 검색하는 것보다 시간이 오래 걸릴 것으로 예상해야합니다.
모든 행을 묻는다면 항상 검색을 받게됩니다.
400,000 개의 행 X112 개의 열 X17 바이트는 761,600,000 바이트입니다. (저는 17 공중에서 뽑았습니다.) 2 분의 3 분의 1을 네트워크를 가로 질러 옮기는 것은 나쁘지 않습니다. 이는 서버에 예약 된 디스크 백업의 처리량과 비슷합니다.
더 빠른 네트워크에 돈이 있습니까?
얼마나 많은 데이터가 테이블에 있습니까 (바이트)? 어떤 종류의 네트워크 연결이 있습니까? 많은 양의 데이터에 대해서는 2 분이 적당합니다. – Oded
모든 레코드를 반환하기 때문에 스캔을하고 있으므로 검색 할 이유가 없습니다. @Oded와 마찬가지로, 성능은 네트워크를 기반으로합니다 ... 단순히 데이터를 줄이는 방법을 찾지 못하면 병목 현상이 발생합니다. –