MySQL Too Many Connections Hatası Nedir, Nasıl Çözülür?

Sunucudaki bütün siteler aynı anda beyaz ekrana düştüyse ve loglarda ERROR 1040 (HY000): Too many connections satırını görüyorsanız, MySQL çökmedi — kapıyı kapattı. Bu hata, veritabanı sunucusunun aynı anda kabul edebileceği bağlantı sayısının dolduğunu, yeni gelen her isteğin de kapıdan geri çevrildiğini söyler. WordPress tarafında bu genellikle "Veritabanı bağlantı hatası" ekranı olarak, bir e-ticaret uygulamasında 500 hatası olarak, panelden mysql komutuyla bağlanmaya çalıştığınızda da doğrudan 1040 kodu olarak karşınıza çıkar. MySQL bağlantı limiti hatası, kendi VDS'ini yöneten herkesin trafik büyüdükçe er geç çarptığı ilk gerçek eşiktir.

Bu yazıda internette en sık verilen tavsiyeyi — "max_connections değerini artır" — kasten en sona bıraktım, çünkü yıllardır gördüğüm en yaygın yanlış müdahale bu. Limiti artırmak sorunu çözmez, üç gün sonraya erteler ve bu arada sunucunun belleğini sessizce tüketir. Burada önce hangi bağlantının havuzu doldurduğunu SHOW PROCESSLIST ile bulacağız, sonra max_connections artırmanın bellek maliyetini gerçek bir formülle hesaplayacağız, ardından asıl suçlunun neredeyse her zaman limit değil uzun süren sorgular ve kapanmayan bağlantılar olduğunu göstereceğiz. Sonunda elinizde hem beş dakikalık acil müdahale planı hem de tekrarını önleyecek kalıcı yapılandırma olacak.

Too Many Connections Hatası Tam Olarak Ne Anlama Geliyor#

MySQL, aynı anda açık tutabileceği istemci bağlantısı sayısını max_connections değişkeniyle sınırlar; bu sayı dolduğunda yeni bağlantı isteklerine 1040 hatasıyla cevap verir. Yani hata bir arıza değil, bilinçli bir koruma mekanizmasıdır: MySQL bellek tükenip işletim sistemi tarafından öldürülmektense yeni bağlantıyı reddetmeyi tercih eder.

Bağlantı sayısını ve limiti görmek için sunucuya bağlanıp şu iki satırı çalıştırın:

SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

Threads_connected şu anki açık bağlantı sayısıdır. Max_used_connections, MySQL en son başladığından beri görülen zirve değeridir — bu ikisinin farkı çok kritiktir. Threads_connected 20 iken Max_used_connections limitin tam üstündeyse, kısa süreli bir tepe yaşadınız ve şu anda her şey normal görünüyor demektir. Sadece anlık değere bakıp "bende sorun yok" demek, bu hatanın en sık kaçırılma biçimidir.

Bir noktayı da netleştirelim: MySQL, max_connections değerine ek olarak bir bağlantı slotunu SUPER (MySQL 8'de CONNECTION_ADMIN) yetkisine sahip kullanıcılar için ayırır. Bu yüzden sıradan uygulama kullanıcısı 1040 alırken, root ile bağlanabiliyor olabilirsiniz. Bu bir çelişki değil, tam da müdahale edebilmeniz için tasarlanmış bir kaçış kapısıdır — panik anında bunu hatırlayın.

Sık karıştırılan bir başka hata da ERROR 1129 (HY000): Host ... is blocked because of many connection errors. Bu farklı bir mekanizmadır (max_connect_errors) ve çözümü de farklıdır: FLUSH HOSTS;. 1040 ile 1129'u karıştırıp yanlış tarafı kurcalamak epey vakit kaybettirir.

İlk Adım: Bağlantıları Kim Tüketiyor#

Limit dolduğunda yapılacak ilk iş, o bağlantıların kime ait olduğunu görmektir; bunu SHOW FULL PROCESSLIST ile yaparsınız. Ancak çıktı yüzlerce satır olacağı için ham hâliyle okumaya çalışmak zaman kaybıdır. Bunun yerine information_schema üzerinden gruplayarak sorun.

SELECT USER, HOST, DB, COMMAND, COUNT(*) AS adet
FROM information_schema.PROCESSLIST
GROUP BY USER, HOST, DB, COMMAND
ORDER BY adet DESC;

Bu tek sorgu size şunu söyler: bağlantılar tek bir kullanıcıdan mı geliyor, tek bir veritabanına mı yığılmış, yoksa tüm sitelere mi dağılmış. Bir e-ticaret sitesinin veritabanı kullanıcısı tek başına 140 satırla listenin tepesindeyse suçluyu bulmuşsunuz demektir.

İkinci sorgu, bağlantıların ne kadar süredir açık kaldığını gösterir — asıl teşhis buradadır:

SELECT ID, USER, DB, COMMAND, TIME, STATE, LEFT(INFO, 120) AS sorgu
FROM information_schema.PROCESSLIST
WHERE COMMAND <> 'Sleep'
ORDER BY TIME DESC
LIMIT 25;

Çıktıyı şöyle okuyun:

• COMMAND = Sleep ve TIME yüksek (örneğin 3000+): Uygulama bağlantıyı açmış, işini bitirmiş ama kapatmamış. Bu bir sorgu problemi değil, bağlantı yönetimi problemidir.
• COMMAND = Query ve TIME yüksek: Gerçekten uzun süren bir sorgu var. Sorgu bitmediği için bağlantı serbest kalmıyor, arkasından gelen istekler de birikiyor. Bu, vakaların büyük çoğunluğunda asıl nedendir.
• STATE = Waiting for table metadata lock veya Locked: Bir işlem tabloyu kilitlemiş, geri kalan her şey sıraya girmiş. Genelde arka planda çalışan bir ALTER TABLE ya da yedek alma işlemidir.

Komut satırından hızlı bakmak isterseniz MySQL kabuğuna girmeden de aynı bilgiye ulaşabilirsiniz:

mysqladmin -u root -p status
mysqladmin -u root -p processlist | head -40

Sunucunun genel yükünü de aynı anda görmekte fayda var; htop ve uptime çıktısındaki load average değeri MySQL'in mi yoksa PHP süreçlerinin mi sistemi zorladığını hızlıca ayırt ettirir.

Uzun Süren Sorguları Anında Sonlandırmak#

Site kapalıyken ilk hedefiniz kalıcı çözüm değil, nefes aldırmaktır. Yukarıdaki listede TIME değeri çok yüksek bir sorgu gördüyseniz, ID'sini alıp sonlandırın:

KILL QUERY 184213;

KILL QUERY yalnızca çalışan sorguyu iptal eder, bağlantıyı açık bırakır — uygulama tarafında daha az yıkıcıdır. Bağlantının tamamen kapanmasını istiyorsanız KILL 184213; kullanın.

Onlarca uyuyan bağlantı birikmişse tek tek uğraşmak yerine KILL komutlarını toplu üretebilirsiniz:

SELECT CONCAT('KILL ', ID, ';') AS komut
FROM information_schema.PROCESSLIST
WHERE COMMAND = 'Sleep' AND TIME > 600;

Çıkan listeyi gözden geçirip çalıştırın. Buradaki 600 saniye eşiğini keyfî seçmeyin: uygulamanızın en uzun meşru işlemi ne kadar sürüyorsa onun üstünde bir değer olmalı, yoksa devam eden bir ödeme işlemini kesersiniz.

Bu müdahale bir tedavi değil, kanamayı durdurmadır. Beş dakika sonra tablo aynı hâle gelecekse aşağıdaki bölümler asıl işi yapar.

max_connections Artırmadan Önce Bellek Matematiği#

Limiti artırmak, sunucunun belleğinin yetmesi şartıyla geçerli bir çözümdür; yetmiyorsa MySQL'i 1040 hatasından çok daha kötü bir yere, OOM Killer tarafından öldürülmeye götürür. MySQL bellek tüketimini iki parçada düşünün: her zaman ayrılan global tamponlar (en büyüğü innodb_buffer_pool_size) ve her bağlantı için ayrı ayrı ayrılabilen tamponlar.

Bağlantı başına teorik en kötü durumu şu sorguyla kendi sunucunuz için hesaplayın:

SELECT ROUND((@@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size
            + @@join_buffer_size + @@thread_stack + @@binlog_cache_size)
            / 1024 / 1024, 2) AS baglanti_basina_mb;

Diyelim çıktı 3.2 MB geldi ve innodb_buffer_pool_size değeriniz 4 GB. max_connections değerini 150'den 500'e çıkarırsanız, tepe anında ek olarak yaklaşık 1.1 GB daha bellek talep edilebilir. 8 GB RAM'li bir VDS'te buffer pool 4 GB, PHP-FPM süreçleri 2 GB tutuyorsa bu artış sunucuyu swap'e sokar; swap'e giren MySQL de zaten çökmüş sayılır. Karar tablosu şöyle özetlenebilir:

Değeri gerçekten artırmanız gerekiyorsa, önce yeniden başlatmadan deneyin:

SET GLOBAL max_connections = 300;

MySQL 8 kullanıyorsanız değeri yeniden başlatmalarda da koruyan SET PERSIST max_connections = 300; biçimini tercih edin. Kalıcı hâle getirmek için yapılandırma dosyasına da yazın — dosya yolu dağıtıma göre /etc/my.cnf, /etc/mysql/my.cnf veya /etc/mysql/mariadb.conf.d/50-server.cnf olur:

[mysqld]
max_connections = 300
wait_timeout = 120
interactive_timeout = 300

Bir tuzak: max_connections, işletim sistemi tarafından MySQL sürecine verilen açık dosya tanıtıcısı limitiyle sınırlıdır. Değeri 500 yazıp SHOW VARIABLES çıktısında 214 gibi bir sayı görüyorsanız sebep budur. systemd altında düzeltmesi şöyledir:

sudo systemctl edit mysql
# Açılan dosyaya:
# [Service]
# LimitNOFILE=65535
sudo systemctl daemon-reload
sudo systemctl restart mysql

Asıl Suçlu Genelde Limit Değil, Sorgu Süresi#

Bağlantı havuzunun dolmasının matematiği çok basittir: eşzamanlı bağlantı sayısı ≈ saniyedeki istek sayısı × ortalama sorgu süresi. Saniyede 50 istek alan bir site, sorgular 20 milisaniyede bitiyorsa yalnızca 1 eşzamanlı bağlantı kullanır. Aynı site, indeksi düşmüş bir sorgu yüzünden ortalama 3 saniyeye çıktığında 150 eşzamanlı bağlantıya ihtiyaç duyar — ve limitiniz 151'se tam o anda duvara toslar.

Bu yüzden 1040 hatası neredeyse hiçbir zaman "limit küçük" demek değildir; "sorgular yavaşladı" demektir. Yavaşlamanın tipik nedenleri:

1. İndeksi olmayan bir sorgu. Yeni bir eklenti geldi, wp_postmeta üzerinde meta_value ile arama yapıyor ve tablo büyüdükçe her sorgu tam tarama çalıştırıyor.
2. Tablo kilitleri. Gece çalışan bir mysqldump ya da bir OPTIMIZE TABLE, iş saatine sarkmış.
3. Disk doldu ya da I/O tıkandı. Geçici tablolar diske düşüyor, sorgu süresi on katına çıkıyor.
4. Buffer pool küçük. Veri seti belleğe sığmıyor, her sorgu diske gidiyor.

Suçluyu isimlendirmek için yavaş sorgu günlüğünü açın:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';

Yarım saat sonra biriken dosyayı özetleyin:

sudo mysqldumpslow -s t -t 15 /var/log/mysql/slow.log

-s t toplam süreye göre sıralar, -t 15 en tepedeki 15 kalıbı gösterir. Bu çıktının ilk üç satırı, vakaların büyük çoğunluğunda sorunun tamamıdır. Sorgu düzeyinde derinleşmek isterseniz MySQL ve MariaDB performans optimizasyonu rehberi indeks ve EXPLAIN tarafını ayrıntılı anlatıyor.

Kapanmayan Bağlantılar: wait_timeout ve Uygulama Katmanı#

COMMAND = Sleep satırlarının sayısı yüksekse sorun sorguda değil, bağlantı ömründedir. MySQL'in wait_timeout varsayılanı 8 saat gibi son derece uzun bir süredir; PHP betiği çöktüğünde ya da bir kuyruk işçisi takıldığında bağlantı bu süre boyunca havuzda yer kaplar.

SHOW VARIABLES LIKE 'wait_timeout';
SHOW VARIABLES LIKE 'interactive_timeout';

Web uygulamaları için makul bir aralık 60–180 saniyedir. Değeri düşürmek, unutulmuş bağlantıların kendiliğinden temizlenmesini sağlar. Dikkat edilecek nokta: uzun süren toplu işleriniz (rapor üretimi, veri aktarımı) varsa bunları ayrı bir MySQL kullanıcısıyla çalıştırıp o oturuma özel daha yüksek bir timeout verin, genel değeri yükseltmeyin.

Uygulama tarafında en sık görülen üç hata şunlardır:

• Kalıcı bağlantı (persistent connection) açıp havuz yönetmemek. PDO'da PDO::ATTR_PERSISTENT => true ayarını PHP-FPM ile birlikte kullanıyorsanız, her FPM child'ı kendi bağlantısını ömür boyu tutar. Child sayınız 200 ise MySQL'de 200 bağlantı sürekli açık kalır.
• Betik sonunda bağlantıyı kapatmamak ve set_time_limit(0) ile sonsuz çalıştırmak. Takılan betik bağlantıyı da beraberinde takar.
• Her döngü adımında yeni bağlantı açmak. İçe aktarma betiklerinde klasiktir; birkaç bin satırlık bir import, saniyeler içinde limiti doldurur.

En kritik ilişki PHP-FPM ile MySQL arasındadır. Sunucudaki tüm havuzların pm.max_children toplamı, max_connections değerinden küçük olmalıdır — aksi hâlde PHP tarafı MySQL'in kaldırabileceğinden fazla eşzamanlı istek üretmeye çalışır ve fazlası 1040 alır. Bu ayarı PHP-FPM pool ayarları rehberindeki yöntemle hesaplayın; iki değeri birbirinden bağımsız düşünmek bu hatanın en sinsi kaynağıdır.

Belirti ile Neden Eşleme Tablosu#

Aşağıdaki tablo, PROCESSLIST çıktısında gördüğünüz şekle göre nereye bakmanız gerektiğini özetler:

Önbellekleme: Bağlantı Sayısını Kökten Düşürmek#

Bağlantı limiti sorununun en kalıcı çözümü, veritabanına giden istek sayısını azaltmaktır. WordPress gibi her sayfa yüklemesinde onlarca sorgu üreten uygulamalarda nesne önbelleği devreye alındığında Threads_connected değeri belirgin biçimde düşer; çünkü tekrar tekrar okunan seçenek ve meta sorguları artık MySQL'e hiç ulaşmaz.

• Nesne önbelleği: Redis veya Memcached ile tekrar eden sorguları bellekte tutun. WordPress'te bu, bir nesne önbelleği eklentisi ve sunucuya kurulu bir Redis servisiyle birkaç dakikada devreye alınır.
• Tam sayfa önbelleği: Anonim ziyaretçilere HTML'i doğrudan sunmak, o isteklerin veritabanına hiç dokunmamasını sağlar. Trafiğinin çoğu anonim olan bir blogda bu tek başına bağlantı sayısını çok belirgin biçimde düşürür.
• Bot ve tarama trafiği: Ürün filtreleri üzerinde gezinen agresif tarayıcılar, her kombinasyon için önbelleğe girmeyen sorgu üretir. Erişim kayıtlarında tek bir kullanıcı ajanının hâkim olduğunu görürseniz hız sınırlaması uygulayın.

Sitenizin genel yavaşlığı bu hatanın hem sebebi hem sonucu olabildiği için, sitenin neden yavaş açıldığını inceleyen rehberi de aynı oturumda okumanızı öneririm.

Paylaşımlı Hostingte Durum Neden Farklı#

Paylaşımlı hosting hesabındaysanız max_connections değerini değiştiremezsiniz ve zaten değiştirmeniz de gerekmez — sizin için geçerli olan sınır, hesap başına tanımlanan eşzamanlı bağlantı ve süreç limitidir. CloudLinux tabanlı sunucularda bu limitler LVE üzerinden uygulanır ve cPanel'in "Resource Usage" ekranında hangi limite çarptığınızı doğrudan görebilirsiniz.

Burada 1040 hatası genellikle şu üçünden birinin sonucudur: eklenti kaynaklı ağır sorgular, iyi ayarlanmamış bir yedekleme işi, ya da tek bir tabloda kontrolsüz büyüme (wp_options içindeki autoload verisi ya da devasa bir log tablosu). Yapabilecekleriniz sırayla şunlardır:

1. cPanel → Resource Usage ekranından son 24 saatte hangi limite kaç kez çarptığınıza bakın.
2. phpMyAdmin üzerinden en büyük tabloları listeleyin ve gereksiz log/geçici veriyi temizleyin.
3. Sorunu üreten eklentiyi tespit etmek için kademeli devre dışı bırakma yapın.
4. Trafiğiniz gerçekten büyüdüyse paket yükseltmeyi ya da kendi kaynaklarınıza sahip olacağınız bir sunucuya geçmeyi değerlendirin.

Hesap düzeyindeki limitlerin nasıl işlediğini paylaşımlı hosting kaynak limitleri yazısında ayrıntılı anlattık; oradaki eşikleri anlamadan hosting firmasıyla yapılan yazışmalar genelde sonuçsuz kalıyor.

Tekrarını Önlemek: İzleme ve Erken Uyarı#

Bu hatanın en can sıkıcı yanı, siz fark ettiğinizde çoktan yaşanmış olmasıdır. Max_used_connections değerini periyodik olarak kaydederseniz, duvara çarpmadan haftalar önce eğilimi görürsünüz. Basit bir cron görevi bile yeterlidir:

#!/bin/bash
# /usr/local/bin/mysql-conn-log.sh
LIMIT=$(mysql -N -B -e "SELECT @@max_connections;")
USED=$(mysql -N -B -e "SHOW STATUS LIKE 'Threads_connected';" | awk '{print $2}')
PEAK=$(mysql -N -B -e "SHOW STATUS LIKE 'Max_used_connections';" | awk '{print $2}')
echo "$(date +%F\ %T) limit=$LIMIT acik=$USED zirve=$PEAK" >> /var/log/mysql-conn.log
if [ "$USED" -gt $(( LIMIT * 80 / 100 )) ]; then
  echo "UYARI: baglanti kullanimi %80 ustunde ($USED/$LIMIT)" | \
    mail -s "MySQL baglanti uyarisi" [email protected]
fi

Betiği çalıştırılabilir yapıp crontab -e ile beş dakikada bir tetikleyin (*/5 * * * * /usr/local/bin/mysql-conn-log.sh). Daha görsel bir çözüm isterseniz bir sunucu izleme aracı MySQL bağlantı grafiğini hazır olarak sunar ve tepe anlarını geriye dönük incelemenizi sağlar.

Son olarak bir alışkanlık önerisi: her eklenti kurulumundan, her tema değişikliğinden ve her veri aktarımından sonra Max_used_connections değerine bakın. Bu tek satırlık kontrol, "dün akşam her şey normaldi" cümlesini kuran onlarca arıza kaydını daha başlamadan bitirir.

Sıkça Sorulan Sorular#

max_connections değerini artırmak zararlı mı#

Zararlı değil ama bedelsiz de değil. Her ek bağlantı, tepe anında sıralama ve birleştirme tamponları için ayrı bellek talep edebilir; bu yüzden limiti belleğinizin kaldıramayacağı bir yere çekerseniz MySQL 1040 hatası yerine işletim sistemi tarafından tamamen sonlandırılır ve site tümüyle kapanır. Doğru yaklaşım, önce bağlantı başına ortalama tüketimi ölçmek, sonra boştaki belleği hesaba katarak kademeli artırmaktır. Artışı yaptıktan sonra birkaç gün Max_used_connections değerini takip edin.

Hata veriyor ama SHOW PROCESSLIST çıktısı boş görünüyor#

Bu, sorunun kısa süreli tepelerden kaynaklandığını gösterir. Threads_connected anlık değeri düşükken Max_used_connections limitin üstündeyse, saniyeler süren bir yığılma yaşanmış ve siz baktığınızda dağılmış demektir. Bu durumda tek çare periyodik ölçüm almaktır: beş dakikada bir bağlantı sayısını kaydeden bir betik ya da bir izleme aracıyla tepe anlarını yakalayın. Ayrıca yavaş sorgu günlüğünü açık bırakmak, tepe anında hangi sorgunun biriktiğini geriye dönük gösterir.

Uyuyan Sleep bağlantılarını toplu olarak kapatmak güvenli mi#

Yeterince uzun süredir uyuyan bağlantılar için genelde güvenlidir, çünkü uygulama o bağlantı üzerinde bir işlem yürütmüyordur. Yine de eşiği rastgele seçmeyin: uygulamanızın en uzun meşru işleminden yüksek bir değer belirleyin, aksi hâlde devam eden bir ödeme veya içe aktarma işlemini yarıda kesebilirsiniz. Ayrıca bu bir tedavi değil semptom bastırmadır; bağlantılar neden kapanmıyor sorusunu yanıtlamadan kalıcı çözüm olmaz.

WordPress veritabanı bağlantı hatası ile bu hata aynı şey mi#

Aynı değil ama sık sık aynı kökten gelirler. WordPress ekranındaki "Veritabanı bağlantı hatası" yazısı; yanlış kullanıcı adı ve parola, MySQL servisinin durmuş olması veya bağlantı limitinin dolması gibi birbirinden çok farklı durumların hepsinde çıkar. Ayrımı yapmak için sunucudan doğrudan mysql -u kullanici -p ile bağlanmayı deneyin: 1040 alıyorsanız limit dolmuştur, 1045 alıyorsanız kimlik bilgisi yanlıştır, bağlantı hiç kurulmuyorsa servis kapalıdır.

wait_timeout değerini düşürmek açık oturumları bozar mı#

Web uygulamaları için bozmaz, çünkü her HTTP isteği kendi bağlantısını açıp kapatır ve saniyeler içinde işini bitirir. Riskli olan senaryo, uzun süren toplu işlemler ve raporlama betikleridir; bunlar bağlantıyı açık tutup uzun süre bekleyebilir. Çözüm, genel değeri düşük tutup bu işleri ayrı bir kullanıcıyla çalıştırmak ve oturum düzeyinde SET SESSION wait_timeout ile daha uzun bir süre vermektir. Böylece havuzu tıkayan sıradan bağlantılar temizlenirken meşru uzun işler etkilenmez.

Paylaşımlı hostingte bu hatayı ben çözebilir miyim#

Sunucu genelindeki limiti değiştiremezsiniz, ama hesabınızın o limite yaptığı baskıyı azaltabilirsiniz. Ağır sorgu üreten eklentileri tespit edip kaldırmak, tam sayfa önbelleği açmak, şişmiş log ve geçici veri tablolarını temizlemek ve kontrolsüz bot trafiğini sınırlamak doğrudan sizin elinizdedir. Bunları yaptıktan sonra hâlâ limite çarpıyorsanız sorun artık yapılandırmada değil kapasitededir; paket yükseltmek ya da kendi kaynaklarınıza sahip olduğunuz bir sunucuya geçmek gerekir.

Hata sadece gece belirli saatlerde çıkıyorsa nedeni ne olabilir#

Belirli saatlerde tekrarlayan bağlantı yığılmasının nedeni neredeyse her zaman zamanlanmış bir görevdir. Yedekleme işlemleri, veritabanı optimizasyonu, dış servislerle veri senkronizasyonu ve toplu e-posta gönderimleri tablo kilitleyip bağlantı biriktirir. crontab -l çıktısını ve uygulamanızın kendi zamanlanmış görev listesini o saatlerle karşılaştırın. Çakışan işleri farklı saatlere dağıtmak, çoğu vakada tek başına sorunu bitirir.

Kapanış#

MySQL "Too many connections" hatası, bir kapasite sorunundan çok bir teşhis sorunudur: hata mesajı size limitten bahseder ama gerçek neden hemen her zaman sorguların yavaşlaması ya da bağlantıların kapanmamasıdır. Bu yüzden doğru sıra nettir — önce SHOW PROCESSLIST ile havuzu kimin doldurduğunu görün, uzun sorguları sonlandırıp nefes aldırın, yavaş sorgu günlüğüyle suçluyu isimlendirin, wait_timeout ve PHP-FPM child sayısını hizalayın; max_connections artırımını ancak bellek hesabını yaptıktan sonra ve en son adım olarak uygulayın. Bu sırayı takip ettiğinizde hata bir daha aynı biçimde geri gelmez, çünkü ertelemek yerine kaynağını kapatmış olursunuz.

Veritabanı yükünüz tek bir paylaşımlı hesabın sınırlarını zorlamaya başladıysa, kendi bellek ve bağlantı ayarlarınızı özgürce yapabileceğiniz bir VDS sunucu doğal bir sonraki adımdır; MySQL ayarlarını, izlemeyi ve güncellemeleri kendiniz üstlenmek istemiyorsanız sunucu yönetimi hizmeti bu işi devralır. Yoğun sorgu üreten bir mağaza işletiyorsanız kaynakları buna göre planlanmış e-ticaret hosting paketlerine, müdahale sırasında elinizin ayağına dolaşmaması için de düzenli yedekleme çözümüne göz atmanızı öneririm.