چگونه خطای Table doesn't exist را در MySQL رفع کنیم؟

یکی از پرونده‌های عجیبی که سال‌ها پیش روی میز کارم آمد، سایتی بود که صاحبش قسم می‌خورد «دیروز کار می‌کرد و امروز این پیام را می‌دهد: Table doesn't exist». جالب این‌جا بود که دیتابیس سالم بود، فایل‌های دیتابیس هم دست‌نخورده. ریشه، یک اشتباه کوچک در مهاجرت بود که پیشوند جدول‌ها را عوض کرده بود و کد قدیمی هنوز با پیشوند قدیمی کوئری می‌زد. آن تجربه برایم درس شد که در مواجهه با این خطا، اولین سوال نباید باشد «چه کسی جدول را پاک کرد؟» بلکه «کدام جدول گم شده و چرا؟».

پیام Table doesn't exist دقیقاً چه می‌گوید؟

پیام کامل معمولاً این شکل است: Table 'database_name.table_name' doesn't exist. یعنی MySQL به دیتابیس نگاه کرده و جدولی که کوئری خواسته، در آن دیتابیس پیدا نکرده. دو نکتهٔ مهم در همین یک جمله پنهان است: اول، اسم دیتابیس هم در پیام هست و گاهی اشتباه کاربر روی همین است؛ دوم، اسم جدول شامل پیشوند است و همین پیشوند، منبع بسیاری از این خطاهاست.

پیام Table doesn't exist همیشه دربارهٔ «حذف شدن» حرف نمی‌زند؛ خیلی وقت‌ها فقط می‌گوید «من چیزی که می‌خواهی نمی‌بینم».

چهار ریشهٔ اصلی این خطا

در تجربهٔ خودم، این خطا تقریباً همیشه یکی از این چهار ریشه را دارد:

اگر خطا بعد از مهاجرت هاست ظاهر شده، احتمالاً ریشه در پیشوند جدول است. مسیر درست مهاجرت را در مهاجرت سایت وردپرسی به هاست جدید توضیح داده‌ام.

تشخیص: کدام جدول گم شده؟

قبل از هر تغییری، سه کار انجام می‌دهم:

1. خواندن دقیق پیام: اسم کامل جدول را یادداشت می‌کنم.
2. گشتن در دیتابیس: با phpMyAdmin یا CLI لیست جدول‌ها را می‌گیرم: SHOW TABLES LIKE '%keyword%';
3. مقایسه با انتظار: اگر انتظار دارم جدول wp_options باشد ولی فقط wp2_options می‌بینم، مقصر مشخص است.

SHOW TABLES;
SHOW TABLES LIKE 'wp_%';
SHOW TABLES LIKE '%options%';

در وردپرس، پیشوند جدول‌ها در wp-config.php با ثابت $table_prefix تعیین می‌شود. اگر تغییرش داده باشید یا مهاجرتی ناقص انجام شده باشد، این خطا ظاهر می‌شود. اگر سایت شما حتی به صفحهٔ ورود هم نمی‌رسد، راهنمای رفع خطای اتصال به دیتابیس در وردپرس مسیر نجات را نشان می‌دهد.

راه‌حل‌های امن برای هر ریشه

هر ریشه، راه‌حل خودش را دارد:

• پیشوند اشتباه: ابتدا مطمئن شوید کدام پیشوند در دیتابیس واقعی است. سپس $table_prefix را در wp-config.php اصلاح کنید. هرگز این کار را بدون بکاپ انجام ندهید.
• حذف اتفاقی: اگر جدول واقعاً حذف شده، از بکاپ بازیابی کنید. اگر بکاپ ندارید، مسیر بازیابی سایت از بکاپ را ببینید.
• نصب ناقص: افزونه یا وردپرس را دوباره نصب کنید تا جدول‌های گم‌شده ساخته شوند.
• نام دیتابیس: در wp-config.php چهار ثابت DB_NAME، DB_USER، DB_PASSWORD و DB_HOST را با اطلاعات واقعی دیتابیس مقایسه کنید.

در وردپرس چه کنیم؟

در وردپرس، این خطا در سه جا بیشتر دیده می‌شود:

• پیشخوان سفید بعد از ارتقا: معمولاً یک افزونه جدولش را با نسخهٔ جدید هماهنگ نکرده. در این حالت، افزونه را غیرفعال کنید و مجدداً فعال کنید تا جدول‌ها بازسازی شوند.
• بعد از بازیابی بکاپ ناقص: اگر فقط بخشی از دیتابیس بازیابی شده، جدول‌های افزونه‌ها گم می‌شوند. ابتدا بکاپ کامل بگیرید و بعد از بکاپ وردپرس استفاده کنید.
• بعد از مهاجرت: اگر پیشوند جدول‌ها در wp-config.php با پیشوند واقعی نخواند، کل سایت می‌خوابد. تست ساده: یک بار جدول‌های دیتابیس را با phpMyAdmin ببینید.

اگر روی سایت وردپرسی خود پیام‌های PHP زیادی می‌بینید که همراه این خطاست، احتمالاً ریشه در یک افزونهٔ قدیمی است. مقایسهٔ سریع با خطاهای رایج MySQL کمک می‌کند الگو را تشخیص دهید.

بازیابی جدول حذف‌شده

اگر جدول واقعاً حذف شده، سه مسیر دارید:

1. از بکاپ دیتابیس: سریع‌ترین و امن‌ترین راه. اگر بکاپ دارید، فقط همان جدول را بازیابی کنید.
2. از binlog MySQL: در سرورهای اختصاصی، binary log می‌تواند جدول را تا لحظهٔ حذف بازگرداند. این مسیر نیاز به دسترسی root دارد.
3. ساخت دستی جدول: اگر جدول مربوط به یک افزونه است، با نصب مجدد افزونه یا با اجرای اسکریپت نصب مجدد، جدول بازساخته می‌شود.

پیش از هر تلاش برای بازیابی، از آن‌چه باقی مانده بکاپ بگیرید؛ بازیابی بدون بکاپ، قمار است.

پیشگیری از تکرار

سه عادت ساده که در پروژه‌هایم از این خطا جلوگیری می‌کند:

• بکاپ روزانه دیتابیس: مهم‌ترین ابزار پیشگیری. مسیر را در بکاپ دیتابیس وردپرس آورده‌ام.
• ثبت پیشوند جدول‌ها: پیشوند دلخواه (نه wp_) برای امنیت انتخاب کنید و آن را جایی یادداشت کنید.
• تست مهاجرت روی staging: پیش از مهاجرت روی سایت زنده، همان مهاجرت را روی یک نسخهٔ آزمایشی انجام دهید.

اگر خطا در حین اجرای کوئری‌های سنگین ظاهر می‌شود، احتمالاً مشکل عمیق‌تر است. نگاهی هم به تأثیر دیتابیس بر سرعت سایت بیندازید؛ همیشه هم سرعت و هم پایداری دیتابیس به‌هم گره خورده‌اند.

برداشت عملی

خطای Table doesn't exist در نگاه اول ترسناک است، ولی در عمل یکی از قابل‌تشخیص‌ترین خطاهای MySQL است. اگر عادت کنید پیش از هر واکنشی، سه سوال بپرسید — «کدام جدول؟»، «پیشوند چیست؟» و «آخرین تغییر چه بود؟» — تقریباً همیشه در چند دقیقه به ریشه می‌رسید. توصیهٔ من این است که یک چک‌لیست کوچک از جدول‌های کلیدی سایت‌تان داشته باشید تا اگر روزی یکی گم شد، فوراً متوجه شوید. اگر تجربهٔ جالبی از این خطا در پروژه‌های خودتان دارید، در دیدگاه‌ها بنویسید؛ هر مورد واقعی، این راهنما را برای نفر بعدی دقیق‌تر می‌کند. 🗂️