Örnek sorular
Mysql Query OptimizationZorluk 1
MySQL'de bir SELECT sorgusunun önüne EXPLAIN koyduğunuzda ne olur?
- aOptimizer'ın planını, sorguyu çalıştırmadan gösterir✓
- bSorguyu çalıştırır, hem sonuç satırlarını hem de zaman damgalı bir plan özetini döndürür
- cSorguyu eşdeğer ama daha hızlı bir forma yeniden yazıp onu çalıştırır
- dYalnızca o tek ifade için query cache'i devre dışı bırakır, diğer tüm ifadeler için ayarı değiştirmeden bırakır
Açıklama:EXPLAIN, optimizer'dan sorgu için kullanacağı execution plan'ı (erişim tipi, kullanılan index, tahmini satır sayısı vb.) üretmesini ister, sorguyu çalıştırmadan ve veri satırı döndürmeden. Sorguyu yeniden yazıp çalıştırmaz (c) ve query cache'e dokunmaz (d — zaten MySQL 8.0'dan beri query cache yok), ve (b) yanlıştır çünkü düz EXPLAIN asla sorgunun kendi sonuç kümesini döndürmez.
Mysql Query OptimizationZorluk 1
Bir meslektaşınız düz EXPLAIN SELECT * FROM orders WHERE customer_id = 5; çalıştırmanın aslında orders tablosunu tarayacağını ve zamanlama bilgisi döndüreceğini iddia ediyor. Bu doğru mu?
- aEvet,
EXPLAIN her zaman sorguyu çalıştırır ve gerçek zamanlamayı ölçer - bHayır, düz
EXPLAIN yalnızca planı tahmin eder; gerçek zamanlama için EXPLAIN ANALYZE gerekir✓ - cEvet, ama yalnızca index kullanan ve tam tablo taramasını atlayan sorgular için
- dHayır,
EXPLAIN SELECT ifadelerinde asla çalışmaz, yalnızca UPDATE/DELETE'te çalışır
Açıklama:Düz EXPLAIN ifadeyi asla çalıştırmaz — yalnızca optimizer'ın tahmini planını (tahmini satır sayısı, erişim tipi) raporlar. Sorguyu gerçekten çalıştırıp node başına gerçek zamanlama/satır sayısı görmek için EXPLAIN ANALYZE gerekir (MySQL 8.0.18'den beri mevcut). (a) ve (c) düz EXPLAIN'in bir şey çalıştırdığını yanlışlıkla iddia ediyor, (d) ise yanlış — EXPLAIN, SELECT, INSERT, UPDATE, DELETE ve daha fazlasında çalışır.
Mysql Query OptimizationZorluk 1
MySQL 8.0.18'den itibaren, EXPLAIN ANALYZE'ın düz EXPLAIN'e kıyasla eklediği temel fark nedir?
- aYalnızca
INSERT/UPDATE/DELETE'te çalışır, SELECT'te asla çalışmaz - bSorgu metnini daha okunaklı biçimlendirir, ama
EXPLAIN ile aynı tahmini sayıları kullanır - cSorguyu gerçekten çalıştırır ve plana ek olarak node-başına gerçek zamanlama ve satır sayılarını raporlar✓
- d
EXPLAIN'in yerini tamamen alır, tek başına EXPLAIN artık deprecated'dır
Açıklama:EXPLAIN ANALYZE (MySQL 8.0.18+) ifadeyi gerçekten çalıştırır ve her plan node'unu tahminlere ek olarak gerçek ölçülen değerlerle (actual time, actual rows) zenginleştirir, sonra sonuç kümesini atar (planı/zamanlamaları metin olarak yazdırır, satırları değil). SELECT'te çalışır (c doğru, a yanlış), gösterilen sayılar sadece biçimlendirilmiş tahmin değil gerçektir (b yanlış), ve düz EXPLAIN hâlâ tam olarak desteklenmektedir, deprecated değildir (d yanlış).
Mysql Query OptimizationZorluk 2
EXPLAIN çıktısında bir sorgunun type sütunu ALL gösteriyor. Bu, MySQL'in tabloya nasıl eriştiği hakkında ne anlama gelir?
- aMySQL, sorguyu karşılamak için mevcut tüm index'leri aynı anda kullandı
- bMySQL covering index kullandı, bu yüzden tablonun veri sayfalarına hiç dokunmadı
- cMySQL, unique bir key kullanarak tam olarak bir satırı eşleştirdi, mümkün olan en hızlı erişim tipiyle
- dMySQL, her satırı sırayla okuyarak tam tablo taraması yaptı✓
Açıklama:type: ALL, EXPLAIN'de gösterilen en verimsiz erişim tipidir — aramayı daraltan hiçbir index olmadan her satırın sırayla okunduğu tam tablo taraması anlamına gelir. Bu, const (unique/primary key ile tam olarak bir satır, c) veya eq_ref/ref/range gibi verimli bir arama'nın tersidir; aynı anda birden çok index kullanmakla (a) ya da covering index'le (b — o, Extra'da ALL olmayan bir tip ile Using index gösterirdi) ilgisizdir.
Mysql Query OptimizationZorluk 1
EXPLAIN çıktısında, MySQL'in yalnızca değerlendirdiği index'lerin aksine, o tablo erişimi için gerçekten kullanmaya karar verdiği index'i hangi sütun gösterir?
- a
key✓ - b
possible_keys - c
type - d
ref
Açıklama:key sütunu, MySQL'in gerçekten kullanmayı seçtiği index'i gösterir (ya da hiçbiri seçilmediyse NULL). possible_keys (b) yalnızca optimizer'ın değerlendirdiği aday index'leri listeler, bunlar gerçekte kullanılanla eşleşmeyebilir. type (c) erişim yöntemini (ör. ref, range, ALL) tanımlar, index adını değil, ve ref (d) seçilen key'e karşı hangi sütun/sabitin karşılaştırıldığını gösterir, key'in kimliğini değil.
Mysql Query OptimizationZorluk 2
EXPLAIN çıktısındaki key_len sütunu size ne söyler?
- aKullanılan index'te saklanan toplam satır sayısı, sorgunun
WHERE koşulundan bağımsız olarak - bMySQL'in satırları aramak için gerçekten kullandığı, seçilen index'in byte cinsinden uzunluğu✓
- cIndex'lenen kolonun tanımında izin verilen maksimum karakter sayısı
- dSorgu için taranan, tablo başına bir tane olan farklı index dosyalarının sayısı
Açıklama:key_len, seçilen key'in arama için gerçekte kaç byte'ının kullanıldığını raporlar — bir composite index'in tamamen mi yoksa yalnızca öncü kolon(lar)ıyla mı kullanıldığını doğrulamak için yararlıdır. Bir satır sayısı değildir (a), bir kolon uzunluk sınırı değildir (c — kolon genişliklerinden türese de bu kullanımla ilgilidir, şema sınırıyla değil) ve index dosyalarının sayısını vermez (d). MySQL, index_merge erişim yöntemiyle tek bir tablo için birden fazla index'i birleştirebilir; ancak key_len yine raporlanan erişimde kullanılan key parçalarını açıklar.