SQL Server Plan Regresyonu Tespiti

Problem neden önemlidir?

İstatistik, şema veya veri dağılımı değişikliği aynı sorgu için daha pahalı bir plan seçilmesine yol açabilir. Kullanıcılar bunu dağıtım olmasa bile ani süre veya CPU artışı olarak görebilir.

Nasıl teşhis edilir?

Query Store çalışma zamanı aralıklarını plan kimliklerine göre karşılaştırın ve değişimin zamanını belirleyin. Süre artışının yürütme sayısı, parametreler, beklemeler veya eşzamanlılık değişiminden kaynaklanmadığını doğrulayın.

Sorgu mevcut veritabanındaki plan ve çalışma zamanı aralıklarını karşılaştırma için listeler. Kısa veya kısmen dolu son aralık, tamamlanmış aralıklarla doğrudan karşılaştırılmamalıdır.

SELECT TOP (50)
       q.query_id,
       p.plan_id,
       rsi.start_time,
       rsi.end_time,
       rs.count_executions,
       rs.avg_duration,
       rs.avg_cpu_time,
       rs.avg_logical_io_reads
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
JOIN sys.query_store_runtime_stats_interval AS rsi
  ON rsi.runtime_stats_interval_id = rs.runtime_stats_interval_id
ORDER BY q.query_id, rsi.start_time DESC;

Güvenli çözüm yaklaşımı

Kök neden düzeltmesi indeks, istatistik veya sorgu tasarımı olabilir; plan zorlama ise kontrollü bir geçici önlem olarak değerlendirilebilir. Zorlanan planların uygulanabilirliği ve performansı sonraki şema değişikliklerinde yeniden doğrulanmalıdır.

Sürekli monitoring neden gerekir?

Regresyonlar iş yükünün belirli saatlerinde görünür ve tek bir ortalamada saklanabilir. moon süre ve kaynak eğilimlerini izleyerek ilgili sapmaları Slack, PagerDuty veya webhook kanallarına yönlendirebilir.