«خطای MySQL» یک علت واحد نیست. ممکن است وردپرس اصلاً به سرور دیتابیس نرسد، کاربر مجوز کافی نداشته باشد، یک افزونه query نامعتبر اجرا کند، دیسک پر شده باشد یا تراکنش‌ها در انتظار lock بمانند. متن دقیق خطا، زمان رخداد و عملی که آن را ایجاد کرده است مسیر تشخیص را تعیین می‌کند.
پاسخ سریع: قبل از repair یا restore، پیام کامل و timestamp را ثبت کنید. اتصال، فضای دیسک و وضعیت سرویس را کنترل کنید؛ سپس PHP، WordPress و MySQL error log را در همان بازه تطبیق دهید. تغییر تصادفی رمز، حذف جدول یا افزایش بی‌حساب timeout می‌تواند حادثه را پیچیده‌تر کند.
ابتدا خطا را در گروه درست قرار دهید
| نشانه | علت‌های محتمل | اولین بررسی |
|---|---|---|
| Access denied | نام کاربر، رمز، host یا privilege | تنظیمات اتصال و log احراز هویت |
| Connection refused / timeout | سرویس، شبکه، socket یا ظرفیت اتصال | وضعیت سرویس و مسیر شبکه |
| Unknown column/table | migration ناقص یا ناسازگاری نسخه | نام افزونه و schema مورد انتظار |
| Deadlock / lock wait | تراکنش‌های هم‌زمان یا طولانی | transaction و queryهای درگیر |
| Disk full / read only | کمبود فضا، inode یا ایراد storage | فضای volume و log سیستم |
| Table crashed/corrupt | خرابی واقعی جدول | engine، CHECK و backup |
خطای اتصال را از خطای query جدا کنید
اگر تمام صفحات هم‌زمان پیام اتصال نشان می‌دهند، از مسیر تشخیص اتصال دیتابیس وردپرس شروع کنید. اگر فقط ذخیره محصول، جستجو یا گزارش خاصی خراب است، احتمال query یا schema اختصاصی بیشتر است. سالم بودن صفحه اصلی، نوشتن در دیتابیس را تضمین نمی‌کند؛ cache ممکن است صفحه را بدون query تازه تحویل دهد.
در معماری کانتینری، DB_HOST معمولاً نام سرویس یا endpoint شبکه است، نه الزاماً localhost. در سرویس مدیریت‌شده نیز failover، محدودیت connection و TLS می‌تواند مطرح باشد. مقادیر واقعی را با مستندات همان محیط مقایسه کنید و credential را در خروجی عمومی نگذارید.
شواهد را از کجا جمع کنیم؟
- عمل و URL ایجادکننده خطا را همراه زمان دقیق ثبت کنید.
- در debug.log وردپرس و PHP log دنبال نخستین پیام مرتبط بگردید.
- MySQL یا MariaDB error log و وضعیت سرویس را در همان دقیقه ببینید.
- فضای آزاد، inode و رخدادهای I/O را بررسی کنید.
- اگر خطا متناوب است، تعداد درخواست‌ها و connectionهای فعال را با زمان آن تطبیق دهید.
- نام افزونه یا فایل حاضر در stack trace را ثبت و آزمون را در staging تکرار کنید.
نمایش عمومی خطاهای دیتابیس در سایت production مناسب نیست؛ پیام‌ها ممکن است نام جدول، مسیر یا جزئیات query را افشا کنند. خطا را در log محدودشده ثبت کنید و پس از تشخیص، حالت debug نمایشی را خاموش نگه دارید.
خطاهای schema بعد از نصب یا آپدیت افزونه
پیام‌هایی مثل unknown column یا table doesn't exist اغلب نشان می‌دهند کد جدید انتظار schema جدیدی دارد، اما migration کامل نشده است. نسخه کد و نسخه ثبت‌شده افزونه را بررسی کنید. فعال و غیرفعال کردن مکرر افزونه یا ساخت دستی ستون از روی یک راهنمای نامرتبط ممکن است داده و مسیر upgrade رسمی را خراب کند.
ابتدا backup بگیرید، upgrade را روی clone دیتابیس بازتولید و لاگ activation/migration را بخوانید. اگر vendor فرمان رسمی یا repair routine دارد، فقط برای همان نسخه استفاده کنید. SQL حدسی روی production راه‌حل قابل نگهداری نیست.
Lock، deadlock و queryهای طولانی
deadlock الزاماً نشانه خرابی دیتابیس نیست؛ دیتابیس معمولاً یکی از تراکنش‌ها را rollback می‌کند. مسئله زمانی مهم می‌شود که تکرار آن checkout، موجودی یا jobها را مختل کند. ترتیب دسترسی به جدول‌ها، طول تراکنش، retry برنامه و indexهای مرتبط باید بررسی شوند.
افزایش timeout فقط مدت انتظار را بیشتر می‌کند و علت lock را از بین نمی‌برد. قبل از kill کردن session بدانید چه تراکنشی اجرا می‌شود؛ قطع نوشتن سفارش یا migration می‌تواند وضعیت نیمه‌کاره بسازد. برای تحلیل slow query، متن پارامتردار، plan، فراوانی و اثر query مهم‌تر از یک نمونه منفرد است.
کمبود دیسک و منابع
دیتابیس برای data، index، temporary file، binary log و عملیات نگهداری فضا نیاز دارد. وقتی volume پر است، optimize یا ساخت index ممکن است به فضای بیشتری نیاز داشته باشد و وضعیت را بدتر کند. ابتدا رشد مصرف را مشخص کنید و با سیاست retention و افزایش ظرفیت کنترل‌شده فضا آزاد کنید؛ فایل‌های data را دستی حذف نکنید.
پیام too many connections نیز نباید فوراً با افزایش سقف پاسخ داده شود. connection leak، job هم‌زمان، workerهای بیش از ظرفیت و query کند ممکن است ریشه مشکل باشند. ظرفیت دیتابیس و RAM باید همراه با pool برنامه تنظیم شود.
چه زمانی Repair مناسب است؟
تنها وقتی شواهد مشخص از خرابی table دارید به repair فکر کنید. engine جدول تعیین می‌کند چه روشی معتبر است؛ REPAIR TABLE درمان عمومی InnoDB نیست. پیش از هر تغییر، راهنمای Repair امن دیتابیس وردپرس و امکان restore نسخه پشتیبان را بررسی کنید.
اشتباه‌های رایج
- جایگزین کردن فایل‌های دیتابیس میان نسخه‌ها به‌صورت دستی
- حذف table یا row برای ساکت کردن خطا
- افزایش هم‌زمان connection و worker بدون محاسبه RAM
- اجرای optimize هنگام کمبود شدید disk
- انتشار dump یا log دارای اطلاعات مشتری و credential
- نسبت دادن هر خطا به «خرابی دیتابیس»
بعد از رفع خطا
عملیات اصلی سایت را با داده آزمایشی کنترل کنید: خواندن، نوشتن، ورود، cron و در فروشگاه ایجاد سفارش. نرخ خطا و latency را زیر بار عادی مانیتور کنید و علت، تغییر و rollback را ثبت کنید. اگر مشکل از ظرفیت یا migration بوده، alert و مرحله پیشگیری مناسب به فرایند استقرار اضافه شود.
چه زمانی بررسی تخصصی لازم است؟
اگر خطا متناوب، مرتبط با تراکنش مالی، همراه با I/O error یا درگیر چند جدول است، آزمون بیشتر روی production ریسک دارد. سرویس رفع مشکل فنی وردپرس می‌تواند شواهد WordPress، PHP و MySQL را بدون تغییر حدسی کنار هم بررسی کند.
پرسش‌های متداول
آیا نصب دوباره وردپرس خطای MySQL را رفع می‌کند؟
معمولاً نه؛ اگر علت اتصال، schema افزونه، منابع یا storage باشد، جایگزینی فایل‌های هسته آن را برطرف نمی‌کند.
آیا می‌توان خطای SQL را در صفحه سایت نمایش داد؟
در production توصیه نمی‌شود. ثبت محدودشده در log و پاک‌سازی اطلاعات حساس امن‌تر است.
آیا optimize database همه خطاها را حل می‌کند؟
خیر؛ optimize هدف دیگری دارد و برای credential، schema ناقص، lock یا corruption عمومی درمان نیست.