حل خطأ “MySQL server has gone away” و”Too many connections” 2026

مقدمة

يُعدّ خطأ MySQL server has gone away ورسالة “Too many connections” من أكثر أخطاء قواعد البيانات إزعاجاً، إذ يؤديان إلى توقف الموقع أو فشل تنفيذ الاستعلامات وظهور أخطاء للزوار.

في هذا الدليل سنشرح أسباب هذين الخطأين وكيفية حلّهما خطوة بخطوة عبر ضبط إعدادات MySQL وتحسين الاتصالات.

ما معنى خطأ MySQL server has gone away؟

يعني أن الاتصال بين موقعك وخادم قاعدة البيانات انقطع فجأة، إما بسبب انتهاء مهلة الاتصال أو إرسال استعلام أكبر من المسموح أو نفاد موارد الخادم.

يظهر هذا الخطأ عندما ينهي خادم MySQL الاتصال بموقعك قبل أن يكمل الطلب. يحدث ذلك لعدة أسباب: إما أن الاتصال بقي خاملاً مدة أطول من قيمة wait_timeout فأغلقه الخادم، أو أن الموقع أرسل استعلاماً أكبر من قيمة max_allowed_packet (شائع عند استيراد قواعد بيانات كبيرة أو رفع محتوى ضخم)، أو أن الخادم نفد من الموارد تحت ضغط عالٍ. فهم السبب الدقيق هو مفتاح اختيار الحل الصحيح.

رسائل الخطأ الشائعة

• ERROR 2006: MySQL server has gone away
• ERROR 1040: Too many connections
• Lost connection to MySQL server during query

وإذا ظهر خطأ الاتصال بقاعدة البيانات بدلاً من ذلك، راجع: حل خطأ "Error Establishing a Database Connection" في ووردبريس: 7 حلول مضمونة 2026.

الأسباب الرئيسية

حل max_allowed_packet

إذا كان السبب استعلاماً كبيراً، ارفع قيمة الحزمة المسموحة في إعدادات MySQL:

max_allowed_packet = 256M

ضبط wait_timeout

لتفادي انقطاع الاتصال بسبب المهلة، ارفع قيمة المهلة:

wait_timeout = 600
interactive_timeout = 600

حل Too many connections

عند تجاوز عدد الاتصالات المسموح، ارفع الحد أو حسّن إغلاق الاتصالات:

max_connections = 200

تظهر رسالة “Too many connections” عندما يصل عدد الاتصالات المتزامنة بقاعدة البيانات إلى الحد الأقصى المسموح. يحدث هذا غالباً على المواقع المزدحمة أو عند وجود إضافات تفتح اتصالات كثيرة دون إغلاقها. إلى جانب رفع قيمة max_connections، من المهم معالجة السبب الجذري بإغلاق الاتصالات بعد الانتهاء منها وتقليل الاستعلامات الثقيلة، لأن رفع الحد وحده على خادم ضعيف قد يستهلك الذاكرة ويسبّب مشاكل أكبر.

تحسين الاستعلامات والاتصالات

• أضف فهارس (Indexes) للجداول الكبيرة
• أغلق الاتصالات بعد الانتهاء
• استخدم تخزيناً مؤقتاً للاستعلامات
• قلّل الاستعلامات الثقيلة في الإضافات

كثير من حالات هذا الخطأ سببها استعلامات بطيئة أو غير محسّنة تُبقي الاتصالات مفتوحة طويلاً. أضف فهارس (Indexes) للأعمدة المستخدمة في البحث والربط، وتجنّب الاستعلامات التي تجلب صفوفاً ضخمة دفعةً واحدة، وفعّل التخزين المؤقت للاستعلامات وصفحات الموقع لتقليل الضغط على قاعدة البيانات. هذه التحسينات لا تحل الخطأ فحسب، بل تسرّع موقعك بشكل ملحوظ.

إعادة تشغيل خدمة MySQL

sudo systemctl restart mysql     # أو mariadb

بعد تعديل ملف الإعدادات (my.cnf أو my.ini) لن تُطبَّق التغييرات إلا بعد إعادة تشغيل خدمة قاعدة البيانات. على الخوادم المُدارة عبر cPanel يمكنك إعادة تشغيل MySQL من WHM، أما على VPS فتستخدم سطر الأوامر. تأكد بعد إعادة التشغيل من أن الخدمة تعمل بحالة active وأن الموقع يتصل بقاعدة البيانات بشكل سليم.

متى تحتاج إلى خادم أقوى؟

إذا تكرّرت المشكلة رغم الضبط، فقد تكون موارد الخادم غير كافية. وقد يصاحبها نفاد ذاكرة؛ راجع: حل مشكلة تجاوز حد الذاكرة (Memory Limit) ورفع حدود PHP في ووردبريس 2026. عندها يكون الانتقال إلى VPS أقوى هو الحل.

إذا كان موقعك متجراً كبيراً أو يستقبل زيارات عالية، فقد تصل قاعدة البيانات إلى حدودها مهما حسّنت الإعدادات. في هذه الحالة لا يكون رفع القيم حلاً دائماً، بل الانتقال إلى خادم VPS أو مخصّص بموارد أكبر (معالج أقوى وذاكرة أكبر وتخزين NVMe سريع) هو الحل الجذري، لأنه يوفّر اتصالات أكثر وأداءً أعلى لقاعدة البيانات دون اختناقات، ويضمن استقرار متجرك في أوقات الذروة.

لماذا تقل مشاكل قواعد البيانات مع مرام هوست؟

توفّر مرام هوست إعدادات MySQL محسّنة وموارد كافية على خوادم AMD EPYC وتخزين NVMe سريع، ما يقلّل أخطاء الاتصال بقاعدة البيانات.

الخلاصة

خطأ MySQL server has gone away وToo many connections لهما أسباب وحلول واضحة: ضبط max_allowed_packet وwait_timeout وmax_connections وتحسين الاستعلامات. وعند الحاجة، يحل الخادم الأقوى من مرام هوست المشكلة جذرياً.