수백만 행이있는 좁은 테이블에서 쿼리 성능을 향상시킬 수 있습니까?

현재 완료하는 데 평균 2500ms가 걸리는 쿼리가 있습니다. 내 테이블은 매우 좁지 만 4,400 만 행이 있습니다. 성능을 향상시키기 위해 어떤 옵션이 필요합니까?

쿼리

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31'; 

탁자

CREATE TABLE [dbo].[Heartbeats](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [DeviceID] [int] NOT NULL,
    [IsPUp] [bit] NOT NULL,
    [IsWebUp] [bit] NOT NULL,
    [IsPingUp] [bit] NOT NULL,
    [DateEntered] [datetime] NOT NULL,
 CONSTRAINT [PK_Heartbeats] PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

색인

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

색인을 추가하면 도움이됩니까? 그렇다면 어떤 모습일까요? 쿼리는 가끔씩 만 실행되기 때문에 현재 성능이 허용되지만 학습 연습으로 궁금합니다. 더 빨리 할 수있는 방법이 있습니까?

최신 정보

강제 색인 힌트를 사용하도록 쿼리를 변경하면 쿼리가 50ms 내에 실행됩니다.

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats] WITH(INDEX(CommonQueryIndex))
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 

올바른 선택적 DeviceID 절을 추가하면 50ms 범위에 도달합니다.

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' AND DeviceID = 4;

ORDER BY [DateEntered], [DeviceID]원래 쿼리에 추가 하면 50ms 범위에 있습니다.

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

이들은 모두 내가 기대했던 색인 (CommonQueryIndex)을 사용하므로 내 질문이 있다고 생각합니다.이 색인을 이와 같은 쿼리에 사용하도록 강요 할 수 있습니까? 아니면 내 테이블의 크기가 옵티 마이저를 너무 많이 ORDER BY버려서 또는 힌트를 사용해야 합니까?

옵티마이 저가 첫 번째 인덱스를 사용하지 않는 이유 :

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

[DateEntered] 열의 선택 문제입니다.

테이블에 4,400 만 개의 행이 있다고합니다. 행 크기는 다음과 같습니다.

ID의 경우 4 바이트, 장치 ID의 경우 4 바이트, 날짜의 경우 8 바이트, 4 비트 열의 경우 1 바이트. (태그, 널 비트 맵, var col 오프셋, 열 카운트)의 총 17 바이트 + 7 바이트 오버 헤드는 행당 총 24 바이트입니다.

140k 페이지로 제대로 번역됩니다. 4 천 4 백만 행을 저장합니다.

이제 옵티마이 저는 두 가지 작업을 수행 할 수 있습니다.

1. 테이블을 스캔 할 수 있습니다 (클러스터 된 인덱스 스캔)
2. 또는 색인을 사용할 수도 있습니다. 인덱스의 모든 행에 대해 클러스터형 인덱스에서 책갈피 조회를 수행해야합니다.

이제 특정 시점에서 비 클러스터형 인덱스에있는 모든 인덱스 항목에 대해 클러스터형 인덱스에서 이러한 모든 단일 조회를 수행하는 것이 비용이 더 많이 듭니다. 이에 대한 임계 값은 일반적으로 총 조회 수가 총 테이블 페이지 수의 25 % tot 33 %를 초과해야한다는 것입니다.

따라서이 경우 : 140k / 25 % = 35000 행 140k / 33 % = 46666 행.

(@RBarryYoung, 35k는 전체 행의 0.08 %이고 46666은 0.10 %이므로 혼동이 발생한 곳이라고 생각합니다)

따라서 where 절의 결과가 35000에서 46666 행 사이 인 경우 (이것이 최상위 절 아래에 있습니다!) 클러스터되지 않은 클러스터가 사용되지 않고 클러스터 된 인덱스 스캔이 사용될 가능성이 큽니다.

이를 변경하는 유일한 두 가지 방법은 다음과 같습니다.

1. where 절을 더 선택적으로 만드십시오. (가능하다면)
2. *를 삭제하고 몇 개의 열만 선택하면 포함 인덱스를 사용할 수 있습니다.

이제 select *를 사용할 때도 포함 인덱스를 만들 수 있습니다. 그러나 삽입 / 업데이트 / 삭제에 엄청난 오버 헤드가 발생합니다. 최선의 솔루션인지 확인하려면 작업 부하 (읽기 / 쓰기)에 대해 더 많이 알아야합니다.

datetime에서 smalldatetime으로 변경하면 클러스터형 인덱스의 크기가 16 % 감소하고 비 클러스터형 인덱스의 크기가 24 % 감소합니다.

PK가 클러스터 된 특별한 이유가 있습니까? 많은 사람들이 기본적으로 그렇게하기 때문에 PK를 클러스터해야한다고 생각합니다. 아뇨. 클러스터형 인덱스는 일반적으로 이와 같은 범위 쿼리 나 자식 테이블의 외래 키에 가장 적합합니다.

클러스터링 인덱스의 효과는 데이터가 클러스터 b 트리의 리프 노드에 저장되기 때문에 모든 데이터를 묶습니다. 따라서 범위의 '너무 넓은'을 요구하지 않는다고 가정하면 옵티마이 저는 b 트리의 어떤 부분에 데이터가 포함되어 있는지 정확히 알고 행 식별자를 찾은 다음 데이터가있는 곳으로 건너 뛸 필요가 없습니다. (NC 색인을 처리 할 때와 같이)입니다. 너무 넓은 범위는 무엇입니까? 우스운 예는 1 년 분의 레코드 만있는 테이블에서 11 개월의 데이터를 요청하는 것입니다. 통계가 최신 상태라고 가정하면 하루 동안의 데이터를 가져 오는 것은 문제가되지 않습니다. (어제 데이터를 찾고 있고 3 일 동안 통계를 업데이트하지 않은 경우 옵티마이 저가 문제를 일으킬 수 있습니다.)

"SELECT *"쿼리를 실행하고 있기 때문에 엔진은 테이블에있는 모든 열을 반환해야합니다 (누군가가 앱에서 필요로하지 않는 새로운 열을 추가하더라도). 포함 된 열이 있으면별로 도움이되지 않습니다. (인덱스에 테이블의 모든 열을 포함하는 경우 잘못된 작업이 수행됩니다.) 옵티마이 저는 아마도 해당 NC 인덱스를 무시합니다.

그래서 뭐 할까?

NC 인덱스를 삭제하고 클러스터 된 PK를 클러스터되지 않은 것으로 변경하고 [DateEntered]에 클러스터 된 인덱스를 생성하는 것이 좋습니다. 그렇지 않으면 입증 될 때까지 단순할수록 좋습니다.

"*"가있는 한, 큰 차이를 만들 것이라고 생각할 수있는 유일한 것은 인덱스 정의를 다음과 같이 변경하는 것입니다.

CREATE NONCLUSTERED INDEX [CommonQueryIndex] ON [dbo].[Heartbeats] 
(
    [DateEntered] ASC,
    [DeviceID] ASC
)INCLUDE (ID, IsWebUp, IsPingUp, IsPUp)
 WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]

주석에서 언급했듯이 해당 인덱스를 사용해야하지만 그렇지 않은 경우 ORDER BY 또는 인덱스 힌트로 설득 할 수 없습니다.

나는 이것을 조금 다르게 볼 것이다.

• 예, 나는 그것이 오래된 실이라는 것을 알고 있지만 흥미가 있습니다.

날짜 시간 열을 덤프했습니다-int로 변경하십시오. 룩업 테이블이 있거나 날짜를 변환하십시오.

클러스터형 인덱스 덤프-힙으로 남겨두고 날짜를 나타내는 새 INT 열에 비 클러스터형 인덱스를 만듭니다. 즉, 오늘은 20121015입니다. 순서는 중요합니다. 테이블을 얼마나 자주로드하는지에 따라 DESC 순서로 해당 인덱스를 작성하십시오. 유지 보수 비용이 더 높으므로 채우기 비율 또는 파티셔닝을 도입하려고합니다. 파티셔닝은 또한 실행 시간을 줄이는 데 도움이됩니다.

마지막으로 SQL 2012를 사용할 수 있으면 SEQUENCE를 사용해보십시오. 삽입에 대해 identity ()보다 성능이 우수합니다.