SQL Azure 스로틀 링 - 인덱스의 효과

Question

우리 시스템이 공칭 부하에서 스로틀 링 벽에 부딪히는 것을 발견합니다. 인스턴스 당 초 당 120 인서트. 다른 동시 프로세스가 실행 중입니다. 우리는 오프로드/최적화 등을하고 있습니다. 제가 알고 싶은 것은 이것입니다 : 누군가가 인덱스 존재가 스로틀 링에 미치는 영향 수준에 대한 통찰력을 가지고 있습니까? 색인의 존재가 도움이 될 시스템의 다른 곳에서 몇 가지 성능 문제가 있지만 추가 CPU 및 I/O로드로 인해 색인을 추가하는 것을 주저합니다!

여기에서 실제적인 조언을 환영합니다. SQL Azure 전용으로 유지하십시오.

Answer 1

색인을 생성 할 때 물론 쿼리의 오버 헤드와 성능 향상 간의 균형을 평가해야합니다. 색인을 유지 관리하는 오버 헤드가 조절되는 범주에 속하므로 가장 많이 사용되는 인덱스가 사용되지 않습니다.

색인을 추가하면 지금 폐기 된 다른 색인을 제거 할 수 있습니까? 인덱스를 추가 한 결과로 쿼리가 더 적은 스로틀 리소스 (I/O, 메모리, CPU)를 사용합니까?

또한 CPU가 더 이상 I/O 또는 메모리와 같이 단단한 방식으로 스로틀되지 않습니다. 쿼리는 더 느리게 실행되지만 실행됩니다.

결국 인덱스 작성시 또는 새로 고침시를 제외하고는 인덱스가 중요한 조절 원인이되는 것을 거의 경험하지 못했습니다. 그럼에도 SQL Server와 마찬가지로 SQL Azure와 같은 상식이 적용됩니다. 너무 넓지 않은 인덱스를 만들고 인덱스가 기존 쿼리 리소스 소비를 줄이는 지 확인하십시오.

DMV를 사용하면 전체 자원 소비가 감소하는지 확인할 수 있습니다.

Answer 2

기본적으로 제한은 CPU, 메모리 및 디스크 사용량에 따라 달라집니다. 따라서 스로틀 링에 대한 인덱스의 영향은 리소스에 미치는 영향까지로 귀결됩니다. 그래서 이것은 실제로 다른 성능 튜닝 시나리오와 같습니다. 어떤 한계를 치는지 알아 내고, 적은 것을 사용하는 방법을 결정하십시오.

SQL Azure는 모든 멋진 DMV에 대한 액세스 권한이 없기 때문에 주로 SQL Server와 다릅니다. 당신은 여전히 ​​일부는 얻지 만 전부는 아닙니다. 당신이 얻게되는 장점 중 하나는 조절 오류가 발생하면 어떤 리소스를 조절하고 있는지 알려주는 것입니다.

상황에 따라 다음 쿼리가 도움이 될 수 있습니다. 나는 이것을 Glenn Berry에서 훔쳤습니다. 나의 유일한 기여는 Azure에서 실행된다는 것입니다. 그는 Azure가 아닌 설치에 집중하고 있지만 SQL 성능 작업에 대한 많은 조언을 받고 있습니다.

--List query plans and stats ordered by last execution time 
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
     s.max_elapsed_time, s.max_worker_time, (s.total_worker_time/s.execution_count) AS AverageExecutionTime, 
     s.max_physical_reads, s.max_logical_reads, 
     s.max_logical_writes, s.min_rows, s.max_rows 
FROM sys.dm_exec_query_stats as s 
     cross apply sys.dm_exec_sql_text(plan_handle) AS q 
ORDER BY s.last_execution_time DESC 


--List query plans and stats ordered by average execution time 
SELECT TOP(50) q.text, s.last_execution_time, s.execution_count, s.total_worker_time, 
     s.max_elapsed_time, s.max_worker_time, (s.total_worker_time/s.execution_count) AS AverageExecutionTime, 
     s.max_physical_reads, s.max_logical_reads, 
     s.max_logical_writes, s.min_rows, s.max_rows 
FROM sys.dm_exec_query_stats as s 
     cross apply sys.dm_exec_sql_text(plan_handle) AS q 
ORDER BY [AverageExecutionTime] DESC 

--Get 50 most I/O intensive queries 
SELECT TOP(50) OBJECT_NAME(qt.objectid) AS [SP Name], 
qs.total_logical_writes, 
qs.total_logical_reads, 
(qs.total_logical_reads + qs.total_logical_writes) /qs.execution_count AS [Avg IO], 
SUBSTRING(qt.[text],qs.statement_start_offset/2, 
    (CASE 
     WHEN qs.statement_end_offset = -1 
    THEN LEN(CONVERT(nvarchar(max), qt.[text])) * 2 
     ELSE qs.statement_end_offset 
    END - qs.statement_start_offset)/2) AS [Query Text], 
qs.execution_count, 
qs.creation_time 
FROM sys.dm_exec_query_stats AS qs 
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS qt 
WHERE qt.[dbid] = DB_ID() 
ORDER BY [Avg IO] DESC OPTION (RECOMPILE); 

--Get executing requests 
SELECT session_id, blocking_session_id, wait_type, last_wait_type, wait_time, total_elapsed_time, cpu_time, logical_reads, reads, writes 
FROM sys.dm_exec_requests AS r 
ORDER BY wait_time DESC 

Answer 3

클러스터 된 인덱스가있는 PK에 대해서는 GUID를 사용하지 마십시오.