MySQL ve MariaDB’de Yavaş Sorgu Günlüğü Nasıl Etkinleştirilir

Yavaş sorgu günlüğü, yürütme süresi yapılandırılabilir bir eşiği aşan her SQL ifadesini kaydeden, MySQL ve MariaDB’ye yerleşik bir tanılama özelliğidir. Sorgu süresini, kilit süresini, incelenen satırları, gönderilen satırları ve tam SQL metnini yakalar; veritabanı yöneticilerine ve geliştiricilere uygulama performansını düşüren her sorgunun dosya tabanlı kesin bir denetim kaydını sunar.

Bu özelliği etkinleştirmek, veritabanı performans ayarlaması sırasında yapabileceğiniz en yüksek etkili işlemlerden biridir. Genel izleme araçlarının aksine, yavaş sorgu günlüğü gecikmeye neden olan tam ifadeleri tespit eder; bu da onu tek kiracılı bir VPS Hosting ortamından çok düğümlü özel veritabanı kümesine kadar her sunucuda dizin optimizasyonu, sorgu yeniden yapılandırması ve kapasite planlaması için vazgeçilmez kılar.

Yavaş Sorgu Günlüğünün Temel İzlemenin Ötesindeki Önemi

Çoğu ekip, kullanıcılar yavaşlık bildirdikten sonra tepkisel olarak EXPLAIN veya SHOW PROCESSLIST kullanmaya başlar. Yavaş sorgu günlüğü proaktif çalışır: gerçek trafiğin saatler veya günler boyunca kanıtını biriktirir ve manuel inceleme penceresinde hiç görünmeyen aralıklı sorunları yakalar.

Temel operasyonel faydalar şunlardır:

• Darboğaz tespiti — Query_time ile Lock_time oranlarını kullanarak CPU’ya bağlı tam tablo taramalarını kilit çakışması sorunlarından ayırt eder
• Dizin boşluğu analizi — log_queries_not_using_indexes bayrağı, ham yürütme süresinden bağımsız olarak tam tarama gerçekleştiren her sorguyu ortaya çıkarır
• Regresyon tespiti — bir dağıtımdan önce ve sonra günlük anlık görüntülerini karşılaştırmak, yeni kodun daha yavaş sorgu kalıpları getirip getirmediğini ortaya koyar
• Kapasite planlama kanıtı — Rows_examined değerlerinin Rows_sent‘den büyüklük sırası kadar yüksek olması, yük altında katlanarak artan eksik veya yanlış kullanılan dizinlere işaret eder

MySQL ile MariaDB: Yavaş Sorgu Günlüğü Özellik Karşılaştırması

Her iki motor da MySQL 5.1’den miras alınan aynı temel yavaş sorgu günlüğü altyapısını paylaşır; ancak MariaDB bunu birçok anlamlı şekilde genişletmiştir.

MariaDB’deki log_slow_verbosity ve log_slow_rate_limit seçenekleri, her yavaş sorgunun günlüğe kaydedilmesinin kendi başına bir performans yüküne dönüşebileceği yüksek verimli üretim ortamlarında özellikle değerlidir.

Adım 1: Yapılandırma Dosyasını Bulun

MySQL ve MariaDB, dağıtıma ve kurulum yöntemine bağlı olarak farklı varsayılan yollardan yapılandırmalarını okur.

MySQL:

• /etc/my.cnf (RPM tabanlı: RHEL, CentOS, AlmaLinux, Rocky Linux)
• /etc/mysql/my.cnf (Debian/Ubuntu)
• /etc/mysql/mysql.conf.d/mysqld.cnf (mysql-server paketiyle Ubuntu)

MariaDB:

• /etc/my.cnf.d/server.cnf (RPM tabanlı)
• /etc/mysql/mariadb.conf.d/50-server.cnf (Debian/Ubuntu)
• /etc/mysql/mariadb.cnf (eski Debian düzenleri)

Hangi dosyanın etkin olduğundan emin değilseniz, çalışan işlemi sorgulayın:

mysqld --verbose --help 2>/dev/null | grep -A1 "Default options"

Bu, daemon’ın başlangıçta okuduğu dosyaların tam sıralı listesini yazdırır; herhangi bir !includedir dizini de dahil olmak üzere.

Birincil yapılandırma dosyasını tercih ettiğiniz düzenleyiciyle açın:

sudo nano /etc/my.cnf

Adım 2: [mysqld]‘a Yavaş Sorgu Günlüğü Yönergelerini Ekleyin

Tüm yavaş sorgu günlüğü parametreleri [mysqld] bölümüne aittir. Bölüm mevcut değilse, dosyanın başında oluşturun.

[mysqld]
# Core slow query log settings
slow_query_log          = 1
slow_query_log_file     = /var/log/mysql/slow-query.log
long_query_time         = 1

# Log queries that skip index usage entirely
log_queries_not_using_indexes = 1

# Avoid flooding the log with index warnings on low-traffic tables
min_examined_row_limit  = 100

# Log slow administrative statements (ALTER TABLE, OPTIMIZE TABLE, etc.)
log_slow_admin_statements = 1

Parametre açıklaması:

• slow_query_log = 1 — özelliği etkinleştirir; bloğu kaldırmadan devre dışı bırakmak için 0 olarak ayarlayın
• slow_query_log_file — günlük dosyasının mutlak yolu; MySQL/MariaDB işlem kullanıcısının (mysql) üst dizine yazma erişimi olmalıdır
• long_query_time = 1 — saniye cinsinden eşik, ondalık değerleri kabul eder (örn. 500 ms için 0.5); varsayılan 10 saniye web uygulamaları için neredeyse her zaman çok izin vericidir
• log_queries_not_using_indexes — long_query_time‘dan bağımsız olarak tam tarama sorgularını günlüğe kaydeder; küçük tablolardan gelen gürültüyü bastırmak için min_examined_row_limit ile birleştirin
• min_examined_row_limit — bir sorgunun log_queries_not_using_indexes kapsamında günlüğe kaydedilmesi için en az bu kadar satırı incelemiş olması gerekir; önemsiz tek satırlık aramaların günlüğü kirletmesini önler
• log_slow_admin_statements — tabloları kilitleyen ve gecikme kaynağı olarak sıklıkla gözden kaçan şema düzeyindeki işlemleri yakalar

Üretimde etkinleştirmeye değer MariaDB’ye özgü eklemeler:

# MariaDB only — extended per-query statistics in the log
log_slow_verbosity      = query_plan,explain

# MariaDB only — log only 1 in every N qualifying queries (rate limiting)
log_slow_rate_limit     = 10

log_slow_verbosity = query_plan,explain, optimize edicinin yürütme planını doğrudan her günlük girişine ekler; bu sayede üretim yük kalıpları altında yalnızca görünen sorguları tanılarken EXPLAIN‘ı manuel olarak yeniden çalıştırma ihtiyacını ortadan kaldırır — önemli bir zaman tasarrufu sağlar.

Adım 3: Günlük Dosyasını Oluşturun ve İzinleri Ayarlayın

Hedef dizin mevcut değilse, servisi yeniden başlatmadan önce oluşturun ve sahipliği atayın. Bu adımı atlamak, yavaş sorgu günlüğünün sessizce etkinleşmemesinin en yaygın nedenlerinden biridir.

sudo mkdir -p /var/log/mysql
sudo touch /var/log/mysql/slow-query.log
sudo chown mysql:mysql /var/log/mysql/slow-query.log
sudo chmod 640 /var/log/mysql/slow-query.log

SELinux zorunlu sistemlerde (RHEL, CentOS, AlmaLinux), dosya bağlamının da doğru şekilde ayarlanması gerekir:

sudo semanage fcontext -a -t mysqld_log_t "/var/log/mysql(/.*)?"
sudo restorecon -Rv /var/log/mysql

Doğru SELinux bağlamının ayarlanmaması, daemon’ın başarıyla başlamasına ancak günlük dosyasına yazmayı sessizce atlamasına neden olur — /var/log/messages‘da belirgin bir hata üretmeyen sinir bozucu bir uç durum.

Adım 4: Veritabanı Servisini Yeniden Başlatın

Yapılandırma değişikliklerini servis yeniden başlatılarak uygulayın. Modern herhangi bir Linux sunucusunda standart olan systemd tabanlı dağıtımlarda:

# MySQL
sudo systemctl restart mysqld

# MariaDB
sudo systemctl restart mariadb

Eski init.d tabanlı sistemlerde:

# MySQL
sudo service mysqld restart

# MariaDB
sudo service mariadb restart

Yeniden başlatmanın ardından servisin düzgün şekilde başladığını kontrol edin:

sudo systemctl status mysqld    # or mariadb
sudo journalctl -u mysqld -n 50 --no-pager

my.cnf‘daki herhangi bir yanlış yapılandırma başlatmayı engeller ve journal çıktısında görünür.

Adım 5: Yeniden Başlatma Olmadan Çalışma Zamanında Yavaş Sorgu Günlüğünü Etkinleştirin

Yeniden başlatmanın kesintiye yol açtığı üretim sunucularında, MySQL ve MariaDB SET GLOBAL aracılığıyla yavaş sorgu günlüğünün dinamik olarak etkinleştirilmesini destekler. Bu şekilde yapılan değişiklikler hemen geçerli olur ancak my.cnf‘a da yazılmadıkça servis yeniden başlatmalarında kalıcı olmaz.

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow-query.log';
SET GLOBAL long_query_time = 1;
SET GLOBAL log_queries_not_using_indexes = 1;
SET GLOBAL min_examined_row_limit = 100;

Bu, canlı bir sistemde acil tanılama için doğru yaklaşımdır — etkinleştirin, yoğun trafik sırasında 15–30 dakikalık bir örnek alın, ardından yapılandırma dosyasına dokunmadan veya daemon’ı yeniden başlatmadan devre dışı bırakın.

Adım 6: Yapılandırmayı Doğrulayın

MySQL veya MariaDB istemcisine bağlanın:

mysql -u root -p

Ardından sistem değişkeni tablosuna karşı bir kalıp eşleşmesi çalıştırın:

SHOW VARIABLES LIKE '%slow_query%';
SHOW VARIABLES LIKE 'long_query_time';
SHOW VARIABLES LIKE 'log_queries_not_using_indexes';

Doğru yapılandırılmış bir örnek için beklenen çıktı:

+-------------------------------+-------------------------------+
| Variable_name                 | Value                         |
+-------------------------------+-------------------------------+
| slow_query_log                | ON                            |
| slow_query_log_file           | /var/log/mysql/slow-query.log |
+-------------------------------+-------------------------------+

+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| long_query_time | 1.000 |
+-----------------+-------+

+-------------------------------+-------+
| Variable_name                 | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON    |
+-------------------------------+-------+

Yavaş sorgu sayacını kontrol ederek günlüğün yazıldığını da doğrulayabilirsiniz:

SHOW GLOBAL STATUS LIKE 'Slow_queries';

Bu sayaç, dosya günlüğünün etkin olup olmadığından bağımsız olarak bir sorgu long_query_time‘ı her aştığında artar — boş bir günlük dosyasını analiz etmek için zaman harcamadan önce yavaş sorguların gerçekten gerçekleştiğini doğrulamak için kullanışlıdır.

Adım 7: Ham Günlüğü Okuma ve Yorumlama

Yük testi veya yoğun trafik penceresi sırasında günlüğü gerçek zamanlı izlemek için tail kullanın:

sudo tail -f /var/log/mysql/slow-query.log

Tipik bir günlük girişi şöyle görünür:

# Time: 2024-10-11T12:45:23.489187Z
# User@Host: app_user[app_user] @ 10.0.1.45 []  Id: 1042
# Query_time: 4.561529  Lock_time: 0.000115  Rows_sent: 1  Rows_examined: 847293
# Bytes_sent: 512
SET timestamp=1697030723;
SELECT * FROM orders WHERE customer_email = 'user@example.com' ORDER BY created_at DESC;

Her alanın size söyledikleri:

• Query_time — saniye cinsinden toplam duvar saati yürütme süresi
• Lock_time — tablo veya satır kilitlerini beklemek için harcanan süre; Lock_time‘ın Query_time‘a yüksek oranı, eksik bir dizine değil çakışmaya işaret eder
• Rows_sent — istemciye döndürülen satırlar
• Rows_examined — depolama motorunun sonucu üretmek için taradığı satırlar; Rows_examined / Rows_sent oranının 100:1’in üzerinde olması, eksik veya düşük seçici bir dizinin güçlü bir sinyalidir
• Bytes_sent — MariaDB genişletilmiş ayrıntı düzeyinde mevcuttur; gereksiz yere büyük sonuç kümeleri döndüren sorguları tanımlamak için kullanışlıdır

Yukarıdaki örnekte, sorgu 1 satır döndürmek için 847.293 satırı inceledi. customer_email üzerine bir dizin eklemek, Rows_examined‘ı yaklaşık 1’e indirecek ve yürütme süresini 4,5 saniyeden milisaniyenin altına düşürecektir.

Adım 8: Günlüğü mysqldumpslow ve pt-query-digest ile Analiz Edin

Ham günlük dosyasını ölçekte okumak pratik değildir. İki araç, yavaş sorguları toplam etkiye göre toplar ve sıralar.

mysqldumpslow Kullanımı (MySQL/MariaDB ile Birlikte Gelir)

# Top 10 queries by total execution time
sudo mysqldumpslow -s t -t 10 /var/log/mysql/slow-query.log

# Top 10 queries by average execution time
sudo mysqldumpslow -s at -t 10 /var/log/mysql/slow-query.log

# Top 10 queries by rows examined
sudo mysqldumpslow -s r -t 10 /var/log/mysql/slow-query.log

mysqldumpslow, sorgu parametrelerini normalleştirir (değişmez değerleri N veya S ile değiştirir); böylece farklı parametre değerlerine sahip yapısal olarak özdeş sorgular bir arada gruplandırılır — yüksek frekanslı kalıpları tanımlamak için gereklidir.

pt-query-digest Kullanımı (Percona Toolkit — Üretim için Önerilir)

# Install Percona Toolkit (Debian/Ubuntu)
sudo apt-get install percona-toolkit

# Install Percona Toolkit (RHEL/CentOS/AlmaLinux)
sudo yum install percona-toolkit

# Generate a full digest report
sudo pt-query-digest /var/log/mysql/slow-query.log

# Show only the top 5 queries by total time
sudo pt-query-digest --limit 5 /var/log/mysql/slow-query.log

# Output to a file for later review
sudo pt-query-digest /var/log/mysql/slow-query.log > /tmp/slow_query_report.txt

pt-query-digest, her sorgunun parmak izini, toplam yürütme süresini, ortalama süreyi, çağrı sayısını ve yüzdelik dağılımını gösteren sıralı bir rapor üretir. mysqldumpslow‘dan önemli ölçüde daha güçlüdür ve profesyonel DBA’ların yavaş günlük analizi için kullandığı standart araçtır.

Adım 9: logrotate ile Günlük Rotasyonunu Yapılandırın

Rotasyon olmadan, yavaş sorgu günlüğü süresiz olarak büyür. long_query_time 1 saniyeye ayarlanmış yoğun bir sunucuda, dosya günler içinde birkaç gigabayta ulaşabilir.

Özel bir logrotate yapılandırması oluşturun:

sudo nano /etc/logrotate.d/mysql-slow

/var/log/mysql/slow-query.log {
    daily
    rotate 14
    missingok
    notifempty
    compress
    delaycompress
    sharedscripts
    postrotate
        /usr/bin/mysqladmin flush-logs 2>/dev/null || true
    endscript
}

Temel yönergeler açıklandı:

• rotate 14 — 14 günlük sıkıştırılmış arşivi saklar; disk bütçenize ve denetim gereksinimlerinize göre ayarlayın
• compress / delaycompress — döndürülen dosyaları gzip ile sıkıştırır, ancak daemon’ın hâlâ açık tutabileceği bir dosyayı sıkıştırmaktan kaçınmak için sıkıştırmayı bir döngü geciktirir
• postrotate — rotasyonun ardından mysqladmin flush-logs çalıştırır; bu, daemon’a mevcut günlük dosyası tanıtıcısını kapatıp yeni bir tane açması için sinyal verir; bu olmadan MySQL/MariaDB bir sonraki yeniden başlatmaya kadar yeniden adlandırılan dosyaya yazmaya devam eder

Yapılandırmayı test etmek için manuel rotasyonu zorlayın:

sudo logrotate -f /etc/logrotate.d/mysql-slow

Adım 10: Artık Gerekli Olmadığında Yavaş Sorgu Günlüğünü Devre Dışı Bırakın

Yüksek trafikli bir sunucuda düşük eşikle (örn. 0,5 saniye) sürekli yavaş sorgu günlüğü kaydı ölçülebilir I/O yüküne neden olur. Yeterli veri topladıktan sonra devre dışı bırakın:

Yapılandırma dosyası aracılığıyla (kalıcı):

[mysqld]
slow_query_log = 0

Ardından servisi yeniden başlatın:

sudo systemctl restart mysqld   # or mariadb

Çalışma zamanı değişkeni aracılığıyla (anlık, kalıcı olmayan):

SET GLOBAL slow_query_log = 'OFF';

Çalışma zamanı yöntemi üretim saatlerinde tercih edilir — sıfır kesinti süresiyle milisaniyeler içinde geçerli olur.

Gelişmiş: performance_schema‘ı Tamamlayıcı Olarak Kullanma

Yavaş sorgu günlüğü, bir zaman eşiğini aşan sorguları yakalar. performance_schema events_statements_summary_by_digest tablosu, yürütme süresinden bağımsız olarak her farklı sorgu kalıbı için toplu istatistikleri yakalar. Her ikisini birlikte kullanmak tam bir tablo sunar.

SELECT
    DIGEST_TEXT,
    COUNT_STAR,
    ROUND(SUM_TIMER_WAIT / 1e12, 3)     AS total_time_sec,
    ROUND(AVG_TIMER_WAIT / 1e12, 6)     AS avg_time_sec,
    SUM_ROWS_EXAMINED,
    SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

Bu sorgu, tüm ifade geçmişindeki en fazla zaman tüketen ilk 10 sorgu kalıbını ortaya çıkarır — yavaş sorgu günlüğünün hiçbir zaman yakalayamayacağı, milyonlarca kez çalışan ve toplu olarak CPU süresine hâkim olan hızlı sorgular da dahil olmak üzere.

Hosting Ortamı Değerlendirmeleri

Optimal long_query_time eşiği, sunucunun rolüne ve kaynak profiline büyük ölçüde bağlıdır:

• Paylaşımlı hosting ortamları — genellikle my.cnf‘a doğrudan erişim yoktur; hosting sağlayıcısı SUPER veya SYSTEM_VARIABLES_ADMIN yetkisi veriyorsa SET GLOBAL kullanın ya da kontrol paneli aracılığıyla yavaş günlük erişimi talep edin
• VPS ortamları — tam root erişimi tüm yapılandırma parametreleri üzerinde tam kontrol sağlar; cPanel ile VPS kurulumu, doğrudan my.cnf‘a yazan WHM’nin MySQL Yapılandırma Düzenleyicisi aracılığıyla yavaş sorgu günlüğü ayarlarını ortaya çıkarır
• Özel sunucular — yüksek trafikli bir veritabanı çalıştıran bir Özel Sunucu‘da long_query_time‘ı 0.1 saniye kadar düşük ayarlamayı ve günlük hacmini kontrol etmek için log_slow_rate_limit (MariaDB) veya uygulama düzeyinde örnekleme kullanmayı düşünün
• GPU hızlandırmalı analitik iş yükleri — büyük veri kümelerine karşı analitik sorgular çalıştıran GPU Hosting düğümlerinde, uzun süreli analitik sorgular bir kusur değil beklenen davranış olduğundan 5–10 saniyelik bir eşik uygun olabilir

Uygulama yığınınız bir VPS Kontrol Paneli aracılığıyla yönetilen bir web ön ucu içeriyorsa, yavaş sorgu günlüğü zaman damgalarını uygulamanızın HTTP erişim günlüğü zaman damgalarıyla ilişkilendirmek, veritabanı gecikmesini belirli kullanıcı odaklı isteklere kadar izlemek için etkili bir yöntemdir.

Pratik Karar Matrisi: Doğru Eşiği Seçme

Teknik Kontrol Listesi ve Temel Çıkarımlar

Yavaş sorgu araştırmasını kapatmadan önce aşağıdakilerin her birini doğrulayın:

• my.cnf‘daki [mysqld] bölümü slow_query_log = 1, geçerli bir slow_query_log_file yolu ve trafik profilinize uygun bir long_query_time içeriyor
• Günlük dosyası ve üst dizini, yazma izinleriyle mysql sistem kullanıcısına aittir; SELinux sistemlerinde dosya bağlamı mysqld_log_t olarak ayarlanmıştır
• SHOW VARIABLES LIKE '%slow_query%', servis yeniden başlatmasının ardından slow_query_log = ON ve doğru dosya yolunu onaylar
• SHOW GLOBAL STATUS LIKE 'Slow_queries', nitelikli sorguların gerçekten gerçekleştiğini doğrulayan sıfır olmayan ve artan bir sayaç gösterir
• log_queries_not_using_indexes etkindir ve önemsiz tek satırlık aramaların günlüğü doldurmasını önlemek için min_examined_row_limit ile eşleştirilmiştir
• log_slow_admin_statements, beklenmedik tablo kilitlerinin yaygın kaynakları olan ALTER TABLE, OPTIMIZE TABLE ve benzeri DDL işlemlerini yakalamak için etkindir
• mysqladmin flush-logs‘ı çağıran bir postrotate kancasıyla bir logrotate yapılandırması mevcuttur
• Günlüğü toplamak için pt-query-digest veya mysqldumpslow çalıştırdınız ve toplam yürütme süresine göre ilk 3–5 sorguyu belirlediniz
• Tanımlanan her sorgu EXPLAIN (veya MySQL 8.0+’da EXPLAIN ANALYZE) ile analiz edildi ve uygun dizinler eklendi ya da sorgu mantığı yeniden yapılandırıldı
• Optimizasyon döngüsü tamamlandıktan sonra devam eden I/O yükünü en aza indirmek için yavaş sorgu günlüğü devre dışı bırakıldı veya long_query_time yükseltildi

SSS

Yavaş sorgu günlüğünü etkinleştirmek veritabanı performansını etkiler mi?

Tipik bir üretim iş yükünde 1 saniye veya daha yüksek bir eşikte, yük ihmal edilebilir düzeydedir — genellikle toplam sorgu yürütme süresinin %1’inden azdır. Yük yalnızca long_query_time 0,1 saniyenin altına ayarlandığında veya log_queries_not_using_indexes çok sayıda küçük, dizinsiz tabloya sahip bir şemada etkinleştirildiğinde ölçülebilir hale gelir. Bunu azaltmak için log_slow_rate_limit (MariaDB) kullanın veya min_examined_row_limit‘ı yükseltin.

MySQL veya MariaDB’yi yeniden başlatmadan yavaş sorgu günlüğünü etkinleştirebilir miyim?

Evet. SUPER veya SYSTEM_VARIABLES_ADMIN yetkisine sahip herhangi bir MySQL istemci oturumundan SET GLOBAL slow_query_log = 'ON' ve SET GLOBAL long_query_time = 1 kullanın. Değişiklik hemen geçerli olur. Yeniden başlatmalar arasında kalıcı olmaları için aynı değerleri my.cnf‘a yazın.

Yavaş sorgu günlüğünde Query_time ile Lock_time arasındaki fark nedir?

Query_time, sunucunun sorguyu aldığı andan istemciye son satırı gönderdiği ana kadar geçen toplam duvar saati süresidir. Lock_time ise bu toplamın tablo veya satır kilitlerini almak için beklemeye harcanan kısmıdır. Lock_time‘ın Query_time‘a yakın olduğu bir sorgu, dizin sorunu değil kilit çakışması sorunudur — çözüm dizin eklemek değil, işlem tasarımını veya kilit kapsamını azaltmayı içerir.

slow_query_log = ON olmasına rağmen yavaş sorgu günlüğü dosyam neden boş?

En yaygın nedenler şunlardır: (1) hiçbir sorgu henüz long_query_time‘ı aşmadı — SHOW GLOBAL STATUS LIKE 'Slow_queries' ile doğrulayın; (2) günlük dosyası yolu mevcut değil veya mysql kullanıcısının yazma izni yok; (3) SELinux sistemlerinde dosya bağlamı yanlış; (4) slow_query_log_file değişkeni, incelediğinizden farklı bir yola işaret ediyor — SHOW VARIABLES LIKE 'slow_query_log_file' ile onaylayın.

Yavaş sorgu günlüğündeki en zararlı tek sorguyu nasıl bulurum?

pt-query-digest çalıştırın ve R/Call (çağrı başına incelenen satırlar) veya Response time (toplam kümülatif süre) değerine göre sıralayın. Response time sıralamasının en üstündeki sorgu en fazla toplam veritabanı süresini tüketiyor demektir ve EXPLAIN analizi ile dizin optimizasyonu için ilk hedef olmalıdır. pt-query-digest mevcut değilse, tek en yüksek toplam süreli sorguyu çıkarmak için mysqldumpslow -s t -t 1 kullanın.