SQL Azureスロットル - インデックスの効果

Question

私たちのシステムは、公称負荷、たとえば1秒あたり120インサートでスロットル壁に当たっています。私たちがオフロード/最適化などを行っている他の同時プロセスがあります。私が知りたいのは、誰かがインデックスの存在がスロットリングに及ぼす影響のレベルについての洞察を持っていますか？システムのどこかにインデックスの存在が役立ついくつかのパフォーマンス上の問題がありますが、CPUとI/O負荷が増えるため、インデックスを追加することを躊躇しています。

ここで実際にアドバイスをいただければ幸いです。 SQL Azure固有のものを保管してください。

Answer 1

インデックス作成時には、クエリのオーバーヘッドとパフォーマンスの向上のトレードオフを評価する必要があります。索引を維持するオーバーヘッドが抑制対象のカテゴリに入るため、最も重要なのは、使用されていないインデックスです。

インデックスを追加すると、現在廃止されている別のインデックスを削除できますか？インデックスを追加した結果、クエリの消費量が少ない（I/O、メモリ、CPU）

CPUはもはやハードな方法（I/Oやメモリなど）でスロットルされないことにも注意してください。クエリは遅く実行されますが、実行されます。

最後に、索引の作成時（またはリフレッシュ時など）を除いて、索引が重大な原因となることはめったにありません。それにもかかわらず、SQL AzureのようにSQL Serverのような常識は適用されません。広すぎないインデックスを作成し、インデックスが既存のクエリリソースの消費を削減することを確認します。

DMVを使用すると、全体のリソース消費が低下しているかどうかを判断するのに役立ちます。

Answer 2

スロットルは基本的にCPU、メモリ、ディスク使用量の制限です。そのため、インデックスへのインパクトは、そのリソースへの影響につながります。だから実際これは他のパフォーマンスチューニングのシナリオと同じです。あなたが打つ限界を見つけ出し、それをいかに少なく使うかを決めます。

SQL Azureは、主にすべてのクールなDMVにアクセスできないため、SQL Serverとは異なります。あなたはまだそれらのすべてではなく、いくつかを取得します。あなたが得る利点の1つは、スロットルエラーが発生している場合、どのリソースを抑制しているのかを教えてください。

状況によっては、次のクエリが役立つ場合があります。私は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を使用しないでください。