MySQL ve MariaDB Temel Performans Ayarları

MySQL optimizasyon çalışmaları çoğu zaman sihirli bir yapılandırma dosyası arayışıyla başlar, oysa performansın büyük kısmı birkaç temel ayarın sunucu kaynaklarına göre doğru belirlenmesinden gelir. MySQL ve MariaDB, varsayılan ayarlarıyla küçük bir test makinesinde bile çalışabilecek şekilde gelir; bu yüzden VDS'inizdeki RAM ve NVMe diskten tam yararlanmak için ayarları elle düzenlemeniz gerekir. Bu rehberde yapılandırma dosyalarının dağıtıma göre yerlerini, en çok etki eden parametreleri ve değişikliklerin etkisini nasıl ölçeceğinizi anlatıyoruz.

Önce Ölçün, Sonra Ayarlayın

Ayar değiştirmeden önce sorunun gerçekten veritabanında olduğundan emin olun. Sayfa yavaşlığının sebebi bazen PHP, bazen disk, bazen de tek bir indekssiz sorgudur. Sunucu genelindeki kaynak kullanımını htop, iostat ve vmstat ile inceleyin; bu araçları Linux sunucu performans izleme yazımızda anlattık.

Veritabanı tarafında ilk bakılacak yerler şunlardır:

sudo mariadb -e "SHOW GLOBAL STATUS LIKE 'Threads_connected';"
sudo mariadb -e "SHOW FULL PROCESSLIST;"
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

MySQL kullanıyorsanız komutlarda mariadb yerine mysql yazın. Bir de altın kural: her seferinde tek bir ayarı değiştirin ve etkisini gözlemleyin. Aynı anda on ayarı değiştirirseniz hangisinin işe yaradığını, hangisinin sorun çıkardığını bilemezsiniz.

Yapılandırma Dosyaları Nerede?

Dosya yolları hem dağıtıma hem de MySQL mi MariaDB mi kullandığınıza göre değişir:

Paket güncellemelerinde ana dosyaların üzerine yazılma riskini önlemek için kendi ayarlarınızı ayrı bir dosyada toplamak iyi bir alışkanlıktır. Dosyalar alfabetik sırayla okunur ve sonra okunan değer öncekini ezer. Örneğin Ubuntu'da MariaDB için /etc/mysql/mariadb.conf.d/90-ayarlar.cnf, AlmaLinux'ta /etc/my.cnf.d/zz-ayarlar.cnf oluşturabilirsiniz. Ayarların [mysqld] başlığı altında olması gerekir.

En Önemli Ayar: innodb_buffer_pool_size

InnoDB tamponu, tablo verilerinin ve indekslerin bellekte önbelleğe alındığı alandır. Sık okunan veri buradan geldiğinde diske hiç gidilmez. Bu nedenle performansa en çok etki eden tek ayardır. Varsayılan değer 128 MB'tır ve bu, gerçek bir uygulama için neredeyse her zaman yetersizdir.

Değeri belirlerken sunucuda başka neyin çalıştığını hesaba katın:

• Yalnızca veritabanı çalışan sunucu: Toplam RAM'in yaklaşık yüzde 50 ile 70'i yaygın bir başlangıç noktasıdır.
• Web sunucusu, PHP ve veritabanı aynı VDS'te: PHP-FPM süreçlerine ve işletim sistemine yer bırakmak için RAM'in dörtte biri ile üçte biri arası daha güvenlidir.
• Veritabanınız küçükse: Toplam veri ve indeks boyutundan biraz büyük bir değer yeterlidir; fazlası boşa ayrılmış bellektir.

Veritabanlarının toplam boyutunu görmek için:

SELECT table_schema AS veritabani,
       ROUND(SUM(data_length + index_length) / 1024 / 1024) AS boyut_mb
FROM information_schema.tables
GROUP BY table_schema;

Tamponun yeterli olup olmadığını anlamak için diskten yapılan okumaları toplam okuma istekleriyle karşılaştırın:

SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

Innodb_buffer_pool_reads (diskten okuma) değeri, Innodb_buffer_pool_read_requests (toplam istek) değerinin çok küçük bir kısmı olmalıdır. Sunucu bir süre çalıştıktan sonra disk okumaları hızla artıyorsa tampon küçük kalıyordur. Bu değeri büyütürken sunucunun swap'e düşmediğinden emin olun; veritabanının swap kullanması, küçük bir tampondan çok daha kötü sonuç verir. Swap'in rolünü Linux'ta swap alanı oluşturma yazımızda açıkladık.

InnoDB Günlük ve Yazma Ayarları

Redo log boyutu

InnoDB, değişiklikleri önce redo log'a yazar. Bu alan küçükse yoğun yazma altında sık sık kontrol noktası oluşturulur ve yazma performansı düşer. MariaDB'de ayarın adı innodb_log_file_size'dır. MySQL 8.0.30 ve sonrasında ise bunun yerine innodb_redo_log_capacity kullanılır. Yazma ağırlıklı sistemlerde birkaç yüz MB ile 1 GB arası değerler yaygındır; okuma ağırlıklı küçük sitelerde varsayılan değer çoğu zaman yeterlidir.

innodb_flush_log_at_trx_commit

Bu ayar, her işlemde (transaction) günlüğün diske ne zaman yazılacağını belirler:

• 1 (varsayılan): Her işlem diske yazılır. Elektrik kesintisinde bile onaylanmış veri kaybolmaz. Finans, sipariş ve üyelik verisi için doğru seçim budur.
• 2: Günlük her işlemde işletim sistemine verilir ama diske saniyede bir yazılır. Yazma performansı artar; işletim sistemi çökmesi veya elektrik kesintisinde son bir saniyelik işlemler kaybolabilir.
• 0: Önerilmez; veritabanı sürecinin çökmesinde bile veri kaybı yaşanabilir.

Verinin değerini bilmeden bu ayarı değiştirmeyin. NVMe SSD'ler senkron yazmada eski disklere göre çok daha hızlı olduğu için 1 değeri çoğu durumda zaten yeterli performansı verir.

innodb_flush_method

Veriyi işletim sisteminin önbelleğini atlayarak doğrudan diske yazan O_DIRECT, aynı verinin hem InnoDB tamponunda hem de işletim sistemi önbelleğinde iki kez tutulmasını önler. MariaDB 10.6 ve sonrasında varsayılan değer zaten O_DIRECT'tir. MySQL 8.0'da Linux üzerindeki varsayılan fsync olduğundan, değeri kontrol edip uygunsa O_DIRECT olarak ayarlayabilirsiniz.

Bağlantı ve Bellek Ayarları

max_connections

Varsayılan değer 151'dir. Bu sınırı körü körüne binlere çıkarmak yaygın bir hatadır, çünkü her bağlantı kendi tampon belleklerini kullanır ve ani bir trafik artışında sunucunun belleğini tüketebilir. Önce gerçekte kaç bağlantı kullanıldığına bakın:

SHOW GLOBAL STATUS LIKE 'Max_used_connections';

Bu değer sınıra yakın değilse dokunmayın. PHP uygulamalarında bağlantı sayısı genellikle PHP-FPM'in pm.max_children değeriyle ilişkilidir; ikisini birlikte planlayın.

tmp_table_size ve max_heap_table_size

Karmaşık GROUP BY ve ORDER BY sorguları geçici tablolar oluşturur. Bu iki ayar, geçici tablonun bellekte tutulabileceği en büyük boyutu belirler ve gerçek sınır ikisinden küçük olanıdır. Bu yüzden ikisine aynı değeri verin. Ancak bu bellek her oturum için ayrı ayrı kullanılabilir. Değeri GB seviyelerine çıkarmak, eşzamanlı sorgular aynı anda büyük geçici tablolar oluşturduğunda sunucunun belleğini bitirebilir ve işletim sistemi veritabanı sürecini sonlandırabilir. 32 ile 64 MB arası değerler çoğu sunucu için güvenli bir başlangıçtır.

SHOW GLOBAL STATUS LIKE 'Created_tmp%';

Created_tmp_disk_tables değeri Created_tmp_tables değerine göre yüksekse geçici tablolar sık sık diske taşıyor demektir. Bu durumda önce sorguları ve indeksleri inceleyin; bellek değerini ancak ondan sonra sınırlı ölçüde artırın.

Query cache

Sorgu önbelleği MySQL 8.0'da tamamen kaldırılmıştır. MariaDB'de hâlâ bulunur ancak varsayılan olarak kapalıdır. Yazma işlemi yoğun ve çok çekirdekli sistemlerde kilit çakışması yarattığı için çoğu durumda kapalı kalması önerilir. Önbelleği uygulama katmanında (Redis gibi) yapmak daha verimlidir.

Yavaş Sorgu Günlüğünü Etkinleştirme

Ayar yapmaktan çok daha büyük kazanç çoğu zaman tek bir yavaş sorguyu düzeltmekten gelir. Yavaş sorgu günlüğü bu sorguları bulmanın en kolay yoludur:

[mysqld]
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

Ubuntu'da /var/log/mysql dizini hazır gelir. AlmaLinux'ta MariaDB günlükleri /var/log/mariadb altında tutulur; dosya yolunu buna göre yazın ve dizinin veritabanı kullanıcısı tarafından yazılabilir olduğundan emin olun. Günlükte görünen sorguları EXPLAIN ile inceleyin:

EXPLAIN SELECT * FROM siparisler WHERE musteri_id = 42;

Çıktıda type sütununda ALL görüyorsanız sorgu tüm tabloyu tarıyordur ve ilgili sütuna indeks eklemek genellikle sorunu çözer.

Örnek Başlangıç Yapılandırması

Aşağıdaki örnek; web sunucusu, PHP ve MariaDB'nin aynı sunucuda çalıştığı, 8 GB RAM'li bir VDS için makul bir başlangıç noktasıdır. Değerleri kendi ölçümlerinize göre uyarlayın:

[mysqld]
innodb_buffer_pool_size = 2G
innodb_log_file_size = 512M
innodb_flush_log_at_trx_commit = 1
max_connections = 150
tmp_table_size = 64M
max_heap_table_size = 64M
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1

MySQL 8.0.30 ve sonrasında innodb_log_file_size satırı yerine innodb_redo_log_capacity = 1G gibi bir değer kullanın. Değişiklikleri uygulamak için servisi yeniden başlatın ve ayarın geçerli olduğunu doğrulayın:

sudo systemctl restart mariadb
sudo mariadb -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Servis başlamazsa hatayı sudo journalctl -u mariadb -n 50 ile görün. Yeniden başlatma tüm bağlantıları keseceği için bu işlemi düşük trafikli saatlerde yapın.

Ayardan Önce İndeks ve Sorgu Kontrolü

Yapılandırma ayarları sunucunun genel verimini artırır; ancak tek bir kötü sorgu, en iyi ayarlanmış sunucuyu bile yavaşlatabilir. Pratikte en büyük kazançlar genellikle şu adımlardan gelir:

• WHERE, JOIN ve ORDER BY'da kullanılan sütunlara indeks ekleyin. Birden fazla sütunla filtrelenen sorgularda bileşik indeksler tek sütunlu indekslerden çok daha etkilidir.
• SELECT * yerine gereken sütunları seçin. Özellikle büyük metin alanları olan tablolarda gereksiz veri okunmasını önler.
• Tablo motorunu kontrol edin. Eski projelerde hâlâ MyISAM tablolar bulunabilir. Bu tablolar InnoDB tamponundan yararlanmaz ve yazma sırasında tüm tabloyu kilitler. InnoDB'ye dönüştürmeden önce yedek alın.
• Büyüyen günlük ve oturum tablolarını temizleyin. Hiç silinmeyen kayıtlar zamanla sorguları yavaşlatır.

Yardımcı Araç: MySQLTuner

MySQLTuner, çalışan bir sunucunun istatistiklerini okuyup öneriler sunan bir betiktir. Ubuntu'da sudo apt install mysqltuner ile kurulabilir; dağıtım deposunda bulamazsanız projenin resmi sayfasından edinebilirsiniz. Sağlıklı öneri vermesi için sunucunun en az 24 saat, normal trafik altında çalışmış olması gerekir. Önerilerini doğrudan uygulamak yerine bu yazıdaki mantıkla değerlendirin; araç sunucunuzda başka hangi servislerin çalıştığını bilmez.

Sık Sorulan Sorular

MySQL mi MariaDB mi daha hızlı?

Genel bir kazanan yoktur; sonuç iş yüküne ve sürüme göre değişir. Çoğu web uygulamasında fark, doğru ayarlanmış tampon ve iyi indekslerin yarattığı farkın yanında küçük kalır.

Ayar değiştirdikten sonra sunucuyu yeniden başlatmak şart mı?

Bazı değişkenler SET GLOBAL ile çalışırken değiştirilebilir ve innodb_buffer_pool_size modern sürümlerde dinamiktir. Ancak kalıcı olmaları için yapılandırma dosyasına da yazılmaları gerekir.

innodb_buffer_pool_size değerini RAM'in tamamına eşitleyebilir miyim?

Hayır. İşletim sistemi, bağlantı başına tamponlar ve sunucudaki diğer servisler de belleğe ihtiyaç duyar. Fazla büyük tampon, sunucunun swap'e düşmesine veya veritabanı sürecinin sonlandırılmasına yol açar.

Veritabanını ayrı bir sunucuya taşımak ne zaman mantıklı?

Web ve veritabanı aynı kaynaklar için sürekli yarışıyorsa veya veritabanı tamponu için gereken RAM sunucunun yarısını aşıyorsa ayırmak faydalıdır. Aradaki ağ gecikmesinin düşük olması için iki sunucunun aynı veri merkezinde bulunması önemlidir.

MySQL optimizasyon çalışması tek seferlik bir iş değil, trafiğiniz büyüdükçe tekrarlanan bir ölçüm ve düzeltme döngüsüdür. Veritabanı yoğun projelerde yüksek tek çekirdek performansı ve NVMe disk belirleyicidir; bu noktada Ryzen 9 9950X ve 9950X3D işlemcili sunucular veya kaynakları paylaşmayan Ankara lokasyonlu dedicated sunucu seçenekleri değerlendirilebilir. LEMP yığınının geri kalanını kurmak için LEMP kurulum rehberimize göz atabilirsiniz.