MySQL FLUSH Komutları: Veritabanı Yöneticileri için Eksiksiz Referans

MySQL’nin `FLUSH` ifadesi, sunucuyu yeniden başlatmaya gerek kalmadan dahili önbellekleri yeniden yüklemeye, log dosyalarını kapatıp yeniden açmaya, durum sayaçlarını sıfırlamaya ve bellek içi durumu disk üzerindeki yapılarla senkronize etmeye zorlar. Bu, onu bir veritabanı yöneticisinin kullanımına sunulan en operasyonel açıdan kritik komut ailelerinden biri yapar.

Her bir varyantı, kesin kapsamını ve yan etkilerini anlamak, üretim ortamları için isteğe bağlı bir bilgi değildir. Örneğin, yoğun bir OLTP sisteminde `FLUSH TABLES WITH READ LOCK` komutunun yanlış kullanılması, dakikalarca süren uygulama genelinde yazma durmalarına neden olabilir. Bu referans, MySQL 5.7 ve 8.x arasındaki davranış farklılıkları, InnoDB’ye özgü sonuçlar, replikasyon riskleri ve yetki gereksinimleri dahil olmak üzere her önemli `FLUSH` varyantını kapsamaktadır.

FLUSH Komutlarının Üretimdeki Önemi

MySQL sunucusu, işlemleri hızlandırmak için çok sayıda bellek içi yapı tutar: host bağlantı önbelleği, yetki tablosu önbellekleri, açık tablo tanımlayıcıları, sorgu sonuç önbellekleri ve depolama motoru tampon havuzları. Bu önbellekler çalışma zamanında yetkilidir. Bir yönetici bant dışı değişiklikler yaptığında — yetki tablolarını doğrudan `INSERT`/`UPDATE` ile düzenlemek, log dosyalarını işletim sistemi düzeyinde döndürmek veya `.ibd` dosyalarını taşımak — sunucunun bellek içi görünümü güncelliğini yitirir. `FLUSH` komutları bu farklılığı giderir.

`FLUSH` komutunun vazgeçilmez olduğu temel operasyonel kategoriler:

• `mysqld` yeniden başlatılmadan yetki yayılımı
• Kilit tabanlı anlık görüntüler kullanan tutarlı çevrimiçi yedeklemeler
• `logrotate` veya özel betiklerle entegre log döndürme
• Kıyaslama öncesi performans temel sıfırlamaları
• Ağ topolojisi değişikliklerinden sonra host önbelleği geçersiz kılma
• Bakım pencereleri öncesi depolama motoru dayanıklılık zorunluluğu

Gerekli Yetkiler

Çoğu `FLUSH` varyantı `RELOAD` yetkisini gerektirir. `FLUSH TABLES WITH READ LOCK` ek olarak `LOCK TABLES` yetkisini de gerektirir. MySQL 8.0+’da, geniş kapsamlı `RELOAD` yetkisi verilmeden daha ayrıntılı erişim kontrolüne olanak tanıyan ince taneli dinamik yetkiler (`FLUSH_OPTIMIZER_COSTS`, `FLUSH_STATUS`, `FLUSH_TABLES`, `FLUSH_USER_RESOURCES`) tanıtıldı. Bu yetkileri uygulama veya izleme hesaplarına atarken her zaman en az yetki ilkesini uygulayın.

Tam Referans: MySQL FLUSH Komutları

1. FLUSH PRIVILEGES

“`sql

FLUSH PRIVILEGES;

“`

Bu komut, `mysql` sistem veritabanındaki (`mysql.user`, `mysql.db`, `mysql.tables_priv`, `mysql.columns_priv`, `mysql.procs_priv`) bellek içi yetki tablolarını yeniden yükler. Sunucu bu tabloları başlangıçta okur ve önbelleğe alır. Bu tablolara yapılan doğrudan DML (`INSERT`, `UPDATE`, `DELETE`) işlemleri, normal `GRANT`/`REVOKE` mekanizmasını atlayarak `FLUSH PRIVILEGES` çalıştırılana kadar önbelleği güncel olmayan halde bırakır.

Ne zaman kullanılır:

• `GRANT`/`REVOKE` ifadeleri yerine ham SQL ile yetki tablolarını manuel olarak düzenledikten sonra
• `mysql.user` tablosuna doğrudan ekleme içeren bir mysqldump içe aktarıldıktan sonra
• `mysql` şemasının kısmi yedeği geri yüklendikten sonra

Kritik nüans: `GRANT`, `REVOKE`, `CREATE USER` veya `DROP USER` ifadelerini kullandığınızda MySQL yetki tablolarını otomatik olarak yeniden yükler. `FLUSH PRIVILEGES` yalnızca bu ifadeleri tamamen atladığınızda gereklidir. Gereksiz yere çalıştırmak zararsızdır ancak yetki tablosu önbelleğinde kısa süreli bir kilide neden olur.

Replikasyon notu: `FLUSH PRIVILEGES` varsayılan olarak binary log’a yazılır ve replikaya çoğaltılır. Bu, bir replikasyon topolojisinde kullanıcıları yönetirken genellikle istenen davranıştır.

2. FLUSH TABLES

“`sql

FLUSH TABLES;

FLUSH TABLES tbl1, tbl2;

“`

Bu komut, şu anda açık olan tüm tablo dosyası tanımlayıcılarını kapatır ve bunları tablo tanım önbelleğinden (TDC) kaldırır. Bir sonraki erişimde MySQL, tablo dosyalarını diskten yeniden açar. Bu, bant dışı dosya manipülasyonlarından sonra gereklidir.

Ne zaman kullanılır:

• İşletim sistemi düzeyinde `.frm`, `.ibd` veya `.MYD`/`.MYI` dosyalarını kopyaladıktan veya değiştirdikten sonra
• Çok büyük `table_open_cache` değerine sahip sunucularda tablo önbelleği belleğini serbest bırakmak için
• InnoDB taşınabilir tablo alanı işlemlerinde `IMPORT TABLESPACE` kullanmadan önce ön koşul olarak

Performans değerlendirmesi: Binlerce açık tablosu olan bir sunucuda `FLUSH TABLES` kısa süreliğine global bir kilit alır. Yüksek eşzamanlılıklı sistemlerde bu, fark edilir bir gecikme artışına neden olabilir. Etkiyi en aza indirmek için tabloya özgü formu (`FLUSH TABLES tbl1, tbl2`) tercih edin.

3. FLUSH TABLES WITH READ LOCK (FTWRL)

“`sql

FLUSH TABLES WITH READ LOCK;

— perform backup operations

UNLOCK TABLES;

“`

Bu, en güçlü ve potansiyel olarak en yıkıcı `FLUSH` varyantlarından biridir. Tüm açık tabloları kapatır, sorgu önbelleğini temizler ve tüm veritabanlarındaki yazma işlemlerini engelleyen global bir okuma kilidi alır. Kilit, `UNLOCK TABLES` çalıştırılana veya oturum sona erene kadar devam eder.

Ne zaman kullanılır:

• `mysqldump –single-transaction` gibi araçlarla fiziksel yedek almadan önce (yalnızca InnoDB kullanan veritabanları için bu gereksizdir — aşağıya bakın)
• InnoDB dışı ortamlarda `mysqlpump` veya `xtrabackup` kullanmadan önce
• Karma depolama motorlarında (InnoDB + MyISAM) belirli bir zamana ait tutarlı anlık görüntü oluşturmak için

Kritik tuzak — yalnızca InnoDB veritabanları: Yalnızca InnoDB tablolarını kullanan veritabanları için `FTWRL` neredeyse hiçbir zaman gerekli değildir. `mysqldump –single-transaction`, yazmaları engellemeden tutarlı bir anlık görüntü sağlayan tekrarlanabilir okuma işlemi açar. Bu senaryoda `FTWRL` kullanmak gereksiz yazma durmalarına neden olur.

Replikasyon riski: `FTWRL` bir replikada çalıştırılırsa SQL uygulayıcı iş parçacığını engeller ve kilit süresince replikasyon gecikmesinin birikmesine neden olur. Kilidi serbest bıraktıktan sonra her zaman `Seconds_Behind_Master` izleyin.

Meta veri kilidi etkileşimi: MySQL 5.7+’da `FTWRL`, global kilidi almadan önce tüm aktif işlemlerin tamamlanmasını bekler. Uzun süreli işlemlerin bulunduğu yoğun bir sunucuda bu bekleme süresiz olabilir. `FTWRL` çalıştırmadan önce engelleyici işlemleri belirlemek için `SHOW PROCESSLIST` kullanın.

4. FLUSH HOSTS

“`sql

FLUSH HOSTS;

“`

MySQL, başarısız kimlik doğrulama sayıları dahil bağlantı girişimi geçmişini kaydeden bir host önbelleği tutar. Bir host `max_connect_errors` ardışık başarısız bağlantıyı aşarsa MySQL, önbellek girişi temizlenene kadar o hosttan gelen tüm sonraki bağlantıları engeller.

Ne zaman kullanılır:

• Meşru bir istemci hostu `max_connect_errors` değerini aşması nedeniyle engellendiğinde
• Tekrarlanan TCP bağlantı hatalarına neden olan bir ağ sorununu çözdükten sonra
• Sunucunun istemci ana bilgisayar adlarını çözümleme biçimini etkileyen DNS kayıtlarını değiştirdikten sonra

MySQL 8.0 alternatifi: MySQL 8.0+’da host önbelleği tablosunu doğrudan da kısaltabilirsiniz:

“`sql

TRUNCATE TABLE performance_schema.host_cache;

“`

Bu aynı sonucu elde eder ve otomatik betiklerde daha şeffaftır.

Proaktif yapılandırma: `FLUSH HOSTS` komutuna reaktif olarak güvenmek yerine `max_connect_errors` değerini daha yüksek bir değere (örn. `10000`) ayarlayın veya güvenilir iç ağlarda host önbelleğini tamamen devre dışı bırakmak için `host_cache_size = 0` ayarlayın.

5. FLUSH STATUS

“`sql

FLUSH STATUS;

“`

Çoğu oturum ve global durum değişkenini sıfıra sıfırlar. Bu, `SHOW STATUS` veya `performance_schema` aracılığıyla gösterilen `Com_select`, `Handler_read_rows`, `Innodb_buffer_pool_reads`, `Threads_connected` ve yüzlerce diğer sayacı içerir.

Ne zaman kullanılır:

• Temiz bir ölçüm temeli oluşturmak için kontrollü bir kıyaslamadan hemen önce
• G/Ç ölçümleri üzerindeki etkiyi izole etmek için bir yapılandırma değişikliğinden sonra (örn. `innodb_buffer_pool_size` ayarını değiştirme)
• Öncesi/sonrası sayaç farklarını karşılaştıran performans regresyon testleri yazarken

Önemli sınırlama: `FLUSH STATUS` tüm sayaçları sıfırlamaz. `Uptime`, `Uptime_since_flush_status` gibi değişkenler ve belirli InnoDB dahili ölçümleri etkilenmez. Kapsamlı izleme için, `FLUSH STATUS` komutunun sağlayamadığı iş parçacığı başına ve olay başına ayrıntı sunan `performance_schema` tablolarını doğrudan kullanın.

6. FLUSH LOGS

“`sql

FLUSH LOGS;

FLUSH BINARY LOGS;

FLUSH ERROR LOGS;

FLUSH GENERAL LOGS;

FLUSH SLOW LOGS;

FLUSH RELAY LOGS;

“`

`FLUSH LOGS` tüm sunucu log dosyalarını kapatır ve yeniden açar. MySQL 5.7.2+, belirli log türlerini ayrı ayrı temizleme özelliğini tanıttı; bu, üretimde çok daha tercih edilir bir yöntemdir.

Ne zaman kullanılır:

• Eski log dosyası döndürüldükten sonra MySQL’e yeni bir log dosyası açması için sinyal vermek amacıyla `logrotate` post-rotate betiğinin bir parçası olarak
• Binary log sıra numarasını artıran yeni bir binary log dosyasını zorlamak için (`FLUSH BINARY LOGS` ile eşdeğer)
• Bekleyen tüm yazmaların diske temizlendiğinden emin olmak için eski logları arşivlemeden önce

Binary log özellikleri: `FLUSH BINARY LOGS` yeni bir binary log dosyası oluşturur ve eski dosyaya bir `Rotate_event` yazar. Bu, belirli bir zamana ait kurtarma (PITR) arşivlemesi için binary logları bölümlemenin doğru yoludur. Mevcut binary log dosyası ve konumu `SHOW MASTER STATUS` (MySQL 5.7) veya `SHOW BINARY LOG STATUS` (MySQL 8.4+) ile doğrulanabilir.

logrotate entegrasyon örneği:

“`bash

/etc/logrotate.d/mysql

/var/log/mysql/mysql-slow.log {

daily

rotate 7

missingok

compress

postrotate

mysqladmin -u root -p flush-logs

endscript

}

“`

7. FLUSH QUERY CACHE

“`sql

FLUSH QUERY CACHE;

RESET QUERY CACHE;

“`

Kullanımdan kaldırma uyarısı: MySQL sorgu önbelleği MySQL 5.7.20’de kullanımdan kaldırıldı ve MySQL 8.0’da tamamen kaldırıldı. MySQL 8.0 veya sonraki bir sürümü çalıştırıyorsanız bu komut mevcut değildir.

Sorgu önbelleğinin hâlâ etkin olduğu MySQL 5.6/5.7 ortamları için:

• `FLUSH QUERY CACHE` önbelleğe alınmış sonuçları kaldırmadan sorgu önbelleği belleğini birleştirir
• `RESET QUERY CACHE` önbelleğe alınmış tüm sorgu sonuçlarını tamamen kaldırır

Ne zaman kullanılır (yalnızca MySQL 5.6/5.7):

• Önbelleğe alınmış sonuçların önemli bir bölümünü geçersiz kılan büyük toplu veri değişikliğinden sonra
• `Qcache_free_blocks` değeri `Qcache_total_blocks` değerine göre yüksek olduğunda, bu parçalanmaya işaret eder
• Belleği temiz bir şekilde serbest bırakmak için sorgu önbelleğini devre dışı bırakmadan önce (`SET GLOBAL query_cache_size = 0`)

Modern alternatif: MySQL 8.0+’da sorgu düzeyinde analiz için InnoDB buffer pool ısıtma (`innodb_buffer_pool_dump_at_shutdown`, `innodb_buffer_pool_load_at_startup`) ve `performance_schema` kullanın.

8. FLUSH USER_RESOURCES

“`sql

FLUSH USER_RESOURCES;

“`

MySQL’nin yerleşik hız sınırlama mekanizması tarafından izlenen kullanıcı başına kaynak sayaçlarını sıfırlar. Bu sayaçlar `CREATE USER` veya `GRANT` ifadelerinde tanımlanan sınırları uygular:

• `MAX_QUERIES_PER_HOUR`
• `MAX_UPDATES_PER_HOUR`
• `MAX_CONNECTIONS_PER_HOUR`
• `MAX_USER_CONNECTIONS`

Ne zaman kullanılır:

• Bir kullanıcı saatlik sorgu kotasını tükettiğinde ve sayaç bir sonraki saat sınırında doğal olarak sıfırlanmadan önce erişiminin hemen geri yüklenmesi gerektiğinde
• Bir kullanıcının kaynak limitlerini artırdıktan sonra yeni limitlerin hemen geçerli olmasını istediğinizde
• Test çalıştırmaları arasında kotaları sıfırlamak için geliştirme/test sırasında

Not: Bu komut tüm kullanıcıların sayaçlarını aynı anda sıfırlar. `FLUSH` düzeyinde kullanıcı başına ayrıntı yoktur. Tek bir kullanıcının sayaçlarını sıfırlamanız gerekiyorsa tek seçenek, hesabını `ALTER USER` ile değiştirmek ve ardından `FLUSH USER_RESOURCES` çalıştırmaktır.

9. FLUSH ENGINE LOGS

“`sql

FLUSH ENGINE LOGS;

“`

Tüm depolama motorlarını bekleyen yazma tamponlarını ilgili log dosyalarına temizlemeye zorlar. InnoDB için bu, redo log tamponunun (`innodb_log_buffer_size`) diskteki InnoDB redo log dosyalarına temizlenmesi anlamına gelir.

Ne zaman kullanılır:

• Redo log tutarlılığını sağlamak için InnoDB veri dosyalarının soğuk yedeğini almadan önce
• Tampon ile ilgili veri tutarsızlıklarını dışlamak için depolama motoru sorunlarını giderirken
• MySQL hizmetini durdurmadan önce bakım öncesi kontrol listesinin bir parçası olarak

InnoDB dayanıklılık bağlamı: InnoDB’nin `innodb_flush_log_at_trx_commit` ayarı, her işlem tamamlanmasında redo log’un ne kadar agresif biçimde temizleneceğini kontrol eder. `FLUSH ENGINE LOGS`, bu ayardan bağımsız olarak temizlemeyi zorlayan manuel bir geçersiz kılmadır. Bu, bir işlem tamamlamadan garantili bir dayanıklılık kontrol noktasına ihtiyaç duyduğunuz senaryolarda kullanışlıdır.

10. FLUSH DES_KEY_FILE

“`sql

FLUSH DES_KEY_FILE;

“`

`–des-key-file` sunucu başlatma seçeneğiyle belirtilen DES şifreleme anahtar dosyasını yeniden yükler. Bu anahtar dosyası `DES_ENCRYPT()` ve `DES_DECRYPT()` işlevleri tarafından kullanılıyordu.

Kullanımdan kaldırma uyarısı: `DES_ENCRYPT()` ve `DES_DECRYPT()` işlevleri MySQL 5.7.6’da kullanımdan kaldırıldı ve MySQL 8.0’da kaldırıldı. Bu nedenle bu komut yalnızca eski MySQL 5.6/5.7 kurulumlarında geçerlidir.

Modern şifreleme alternatifi: Üretim şifreleme gereksinimleri için MySQL Keyring eklentileriyle (`keyring_file`, `keyring_okv`, `keyring_aws`) birlikte MySQL’nin yerel bekleyen veri şifrelemesini (`ALTER TABLE … ENCRYPTION='Y'` aracılığıyla InnoDB tablo alanı şifrelemesi) kullanın.

FLUSH Komut Karşılaştırma Tablosu

Replikasyon ve FLUSH: Neler Çoğaltılır

Tüm `FLUSH` komutları replika sunuculara çoğaltılmaz. Bu ayrımı anlamak, HA ve replikasyon topolojilerinde kritik öneme sahiptir:

Varsayılan olarak çoğaltılanlar:

• `FLUSH PRIVILEGES`
• `FLUSH LOGS` (binary log’a `Rotate_event` olarak yazılır)
• `FLUSH USER_RESOURCES`

Çoğaltılmayanlar (oturum yerel veya açıkça hariç tutulanlar):

• `FLUSH TABLES WITH READ LOCK` — binary log’a hiçbir zaman yazılmaz
• `FLUSH STATUS` — yalnızca yerel sunucunun sayaçlarını etkiler
• `FLUSH HOSTS` — yalnızca yerel host önbelleği
• `FLUSH ENGINE LOGS` — yalnızca yerel motor durumu

Normalde çoğaltılacak belirli bir `FLUSH` komutunun çoğaltılmasını önlemek için `LOCAL` veya `NO_WRITE_TO_BINLOG` değiştiricisini kullanın:

“`sql

FLUSH NO_WRITE_TO_BINLOG PRIVILEGES;

FLUSH LOCAL PRIVILEGES; — equivalent shorthand

“`

Bu, bir replikada yetkileri bağımsız olarak yönetirken kullanışlıdır (örn. birincil sunucuda bulunmaması gereken izleme kullanıcıları eklemek).

mysqladmin ile FLUSH İşlemlerini Otomatikleştirme

Birçok `FLUSH` işlemi, cron görevleri ve bakım betiklerinde kullanışlı olan tam bir MySQL istemci oturumu açmadan kabuktan tetiklenebilir:

“`bash

Flush binary logs

mysqladmin -u root -p flush-logs

Flush privileges

mysqladmin -u root -p flush-privileges

Flush host cache

mysqladmin -u root -p flush-hosts

Flush status counters

mysqladmin -u root -p flush-status

“`

Üretim ortamları için, `-p` değerini etkileşimli olarak geçirmek yerine kimlik bilgilerini `chmod 600` izniyle `~/.my.cnf` dosyasında saklayın veya MySQL’nin `mysql_config_editor` ile `–login-path` mekanizmasını kullanın.

Barındırma Ortamı Değerlendirmeleri

`FLUSH` komutlarını çalıştırabilme yeteneği, büyük ölçüde barındırma ortamına ve verilen veritabanı erişim düzeyine bağlıdır. Bir VPS Hosting planında, genellikle MySQL örneğine tam root erişiminiz olur; bu da herhangi bir `FLUSH` varyantını çalıştırabileceğiniz, `my.cnf` dosyasını değiştirebileceğiniz ve log döndürmeyi doğrudan yönetebileceğiniz anlamına gelir. Bu, ciddi veritabanı yönetimi çalışmaları için önerilen minimum ortamdır.

Paylaşımlı Web Hosting‘de veritabanı erişimi genellikle `RELOAD` yetkisi olmayan ayrıcalıksız bir kullanıcıyla sınırlıdır ve bu da çoğu `FLUSH` komutunu kullanılamaz hale getirir. Uygulamanız yetki yönetimi, log döndürme kontrolü veya yedekleme tutarlı anlık görüntüler gerektiriyorsa, paylaşımlı bir ortam kesin bir engel oluşturacaktır.

Yüksek verimli veritabanı iş yükleri için — özellikle sık `FLUSH ENGINE LOGS` işlemleri veya büyük InnoDB buffer havuzları içerenler — Dedicated Servers, bu işlemlerin kesintisiz olmasını sağlamak için gereken G/Ç verimi ve bellek bant genişliğini sunar. 256 GB buffer havuzu verisine sahip bir sunucuda `FLUSH TABLES WITH READ LOCK` işlemi, hızlı NVMe depolama ve özel G/Ç kanallarına sahip bir sunucuya kıyasla ölçülebilir biçimde daha uzun sürer.

MySQL örneğini bir web kontrol paneliyle birlikte yönetiyorsanız, VPS with cPanel, bazı `FLUSH` işlemlerinin (özellikle log döndürme ve yetki yeniden yüklemeleri) kontrol panelinin veritabanı yönetim katmanı tarafından otomatik olarak gerçekleştirildiği yönetilen bir ortam sağlar ve manuel müdahale ihtiyacını azaltır.

Tam kontrol paneli ekosistemi gerektiren veritabanı destekli uygulamalar için, mevcut VPS Control Panels seçeneklerini incelemek, hangi panelin MySQL yönetim iş akışınızla en iyi entegre olduğunu belirlemenize yardımcı olacaktır.

Temel Kontrol Listesi

Üretimde herhangi bir `FLUSH` komutu çalıştırmadan önce bu karar matrisini kullanın:

• `FLUSH TABLES WITH READ LOCK` öncesi: Uzun süreli aktif işlem olmadığını doğrulayın (`SHOW PROCESSLIST`). Veritabanınızın yalnızca InnoDB kullanıp kullanmadığını kontrol edin — kullanıyorsa bunun yerine `–single-transaction` kullanın.
• `FLUSH PRIVILEGES` öncesi: Yetki tablolarında ham DML kullandığınızı doğrulayın. `GRANT`/`REVOKE` kullandıysanız bu komut gereksizdir.
• `FLUSH LOGS` öncesi: Log döndürme betiğinizin MySQL’e yeniden açması için sinyal vermeden önce eski log dosyasını zaten taşıdığından/yeniden adlandırdığından emin olun.
• `FLUSH HOSTS` öncesi: Önce bağlantı hatalarının temel nedenini belirleyin. Altta yatan sorunu çözmeden host önbelleğini temizlemek, hostun tekrar engellenmesine neden olur.
• MySQL 8.0+’da: Betiklerden `FLUSH QUERY CACHE` veya `FLUSH DES_KEY_FILE` çağrılarını kaldırın — bu komutlar mevcut değildir ve hatalara neden olur.
• Replikasyon topolojilerinde: İşlemin replikalara yayılmaması gerektiğinde `FLUSH LOCAL` veya `FLUSH NO_WRITE_TO_BINLOG` kullanın.
• Otomasyon için: Tam MySQL istemci oturumları açmak yerine betiklerde `mysqladmin flush-*` komutlarını kullanın.
• Yetki denetimi: İzleme ve yedekleme hesapları için geniş kapsamlı `RELOAD` yetkisi yerine MySQL 8.0 dinamik yetkilerini (`FLUSH_STATUS`, `FLUSH_TABLES` vb.) tercih edin.

Sıkça Sorulan Sorular

Her GRANT veya REVOKE ifadesinden sonra FLUSH PRIVILEGES çalıştırılması gerekiyor mu?

Hayır. `GRANT`, `REVOKE`, `CREATE USER` ve `DROP USER` komutları yetki tablolarını bellekte otomatik olarak yeniden yükler. `FLUSH PRIVILEGES` yalnızca `mysql` sistem tablolarında doğrudan DML değişikliklerinden sonra gereklidir (örn. `UPDATE mysql.user SET …`).

FLUSH TABLES WITH READ LOCK uygulama kesintisine neden olabilir mi?

Evet. Sunucudaki her veritabanında tüm `INSERT`, `UPDATE`, `DELETE` ve DDL işlemlerini engelleyen global bir yazma kilidi alır. Yoğun bir OLTP sisteminde, birkaç saniyelik `FTWRL` bile bağlantı havuzlarını tüketebilir ve basamaklı uygulama hatalarına neden olabilir. Yalnızca InnoDB kullanan veritabanları için bunu tamamen önlemek amacıyla `mysqldump –single-transaction` kullanın.

FLUSH STATUS, kıyaslama amacıyla MySQL sunucusunu yeniden başlatmakla aynı mı?

Hayır. `FLUSH STATUS` çoğu durum sayacını sıfırlar ancak InnoDB buffer havuzunu temizlemez, bağlantı durumlarını sıfırlamaz veya birikmiş `performance_schema` istatistiklerini etkilemez. Gerçek anlamda temiz bir kıyaslama için, buffer havuzu temizlemeyle birlikte sunucu yeniden başlatması daha doğru olmakla birlikte üretimde pratik değildir.

Bazı MySQL 8.0 belgelerinde FLUSH HOSTS neden bağımsız bir komut olarak yer almıyor?

`FLUSH HOSTS` MySQL 8.0’da hâlâ çalışır, ancak tercih edilen yöntem `TRUNCATE TABLE performance_schema.host_cache` komutudur; bu yöntem daha açık ve kullanıcının `performance_schema` üzerinde `DELETE` yetkisi varsa `RELOAD` yetkisi olmadan da çalıştırılabilir. Her ikisi de aynı sonucu elde eder.

InnoDB üzerinde yoğun yazma yükü sırasında FLUSH ENGINE LOGS çalıştırılırsa ne olur?

InnoDB log tamponunun diske senkron olarak temizlenmesini zorlar; bu, redo log dosyaları yavaş depolama üzerindeyse kısa süreli bir yazma durmasına neden olabilir. NVMe destekli sunucularda etki genellikle milisaniyenin altındadır. Dönen disk veya yoğun yüklenmiş SAN depolamada fark edilir gecikme artışlarına neden olabilir. Mümkün olduğunda bu işlemi düşük trafikli zaman dilimlerinde planlayın.