مقدمه

اولین بار که با خطای «Incorrect key file for table» مواجه شدم، یک فروشگاه اینترنتی کوچک بود که روی هاست اشتراکی اجرا می‌شد. ساعت ۱۰ شب بود و مشتری زنگ زد که صفحه محصولات خطا نشان می‌دهد. من تا آن روز این پیام را ندیده بودم. به‌نظر ساده می‌آمد — فقط یک خطای دیتابیس — اما بعداً فهمیدم که این خطا فقط یک پیام نیست؛ نشانه‌ای از یک بیماری ساختاری در جدول‌های MyISAM است.

در طول سال‌ها کار روی پروژه‌های مختلف، این خطا را در سایت‌های وردپرسی، فروشگاه‌های ووکامرسی و سیستم‌های قدیمی مبتنی بر PHP دیده‌ام. یک الگوی مشترک در همه آن‌ها وجود داشت: استفاده از موتور MyISAM برای جدول‌هایی که به‌شدت در حال نوشتن و خواندن بودند، و یک خاموشی غیرمنتظره سرور. در این مقاله می‌خواهم دقیقاً بگویم این خطا از کجا می‌آید، چه زمانی خطرناک می‌شود و چطور می‌توان آن را به شکل اصولی و بدون از دست دادن داده برطرف کرد.

خطای Incorrect key file for table دقیقاً چیست؟

برای درک این خطا، اول باید بدانید موتور MyISAM چطور داده‌ها را ذخیره می‌کند. هر جدول MyISAM در واقع از سه فایل جداگانه تشکیل می‌شود: فایل .frm که ساختار جدول را نگه می‌دارد، فایل .MYD که داده‌های واقعی را ذخیره می‌کند، و فایل .MYI که ایندکس‌ها را در خود دارد. این تفکیک، در زمان خودش یک نوآوری بود — اما همین تفکیک باعث می‌شود که یک خرابی کوچک در فایل ایندکس، کل جدول را از دسترس خارج کند.

وقتی MySQL تلاش می‌کند یک رکورد را بخواند یا بنویسد، ابتدا باید از طریق فایل ایندکس (.MYI) محل دقیق رکورد در فایل داده (.MYD) را پیدا کند. اگر این فایل ایندکس آسیب دیده باشد — مثلاً به دلیل یک خاموشی ناگهانی، پر شدن دیسک، یا خرابی سخت‌افزاری — MySQL نمی‌تواند این تطابق را برقرار کند. در این لحظه است که خطای «Incorrect key file for table» ظاهر می‌شود.

این خطا در واقع از تابع my_error در کد منبع MySQL تولید می‌شود. پیام کامل معمولاً به این شکل است:

ERROR 1034 (HY000): Incorrect key file for table 'wp_posts'; try to repair it

نکته مهم این است که MySQL خودش در پیام خطا راهنمایی می‌کند: «try to repair it». این یعنی مشکل قابل حل است — اما فقط اگر بدانید چطور.

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

این خطا با خطای «Table is marked as crashed» تفاوت دارد. در آن خطا، خودِ جدول به‌عنوان «خراب» علامت‌گذاری شده است؛ اما در خطای «Incorrect key file»، جدول سالم است اما فایل ایندکس آن با انتظارات MySQL هم‌خوانی ندارد. این تفاوت در روش تشخیص و درمان اهمیت زیادی دارد.

چرا این خطا رخ می‌دهد؟

در تجربه‌ام، پنج علت اصلی برای این خطا وجود دارد که هر کدام امضای خاص خودشان را دارند:

۱. خاموشی ناگهانی سرور (Unexpected Shutdown)

این شایع‌ترین علت است. وقتی سرور به‌صورت ناگهانی خاموش می‌شود — به دلیل قطع برق، اورهیت، یا ریست سخت‌افزاری — MySQL فرصت نمی‌کند که فایل‌های ایندکس را به‌درستی ببندد. نتیجه این است که فایل .MYI با یک هدر نیمه‌نوشته‌شده باقی می‌ماند. دفعه بعد که MySQL تلاش می‌کند این جدول را باز کند، هدر با انتظاراتش هم‌خوانی ندارد.

در یک پروژه، سروری را دیدم که مدیر فنی‌اش هر شب ساعت ۲ بامداد دستی ریبوت می‌کرد. بعد از سه ماه، سه جدول از جدول‌های MyISAM با این خطا مواجه شدند. وقتی دلیلش را بررسی کردم، متوجه شدم که ریبوت دستی بدون دستور mysqladmin shutdown انجام می‌شده و همین باعث خرابی تدریجی ایندکس‌ها شده بود.

۲. پر شدن دیسک (Disk Full)

وقتی فضای دیسک سرور به‌طور کامل پر می‌شود، MySQL نمی‌تواند فایل‌های موقت یا لاگ‌های خود را بنویسد. در مورد جدول‌های MyISAM، اگر دیسک در حین یک عملیات نوشتن پر شود، ممکن است فایل ایندکس با یک ساختار ناقص ذخیره شود. این حالت خطرناک‌تر از خاموشی ناگهانی است، چون خرابی می‌تواند در چند جدول هم‌زمان رخ دهد و شما متوجه آن نشوید تا زمانی که یک کوئری SELECT ساده خطا بدهد.

۳. خرابی سخت‌افزاری (Hardware Failure)

خرابی سکتورهای دیسک، خطاهای RAM، یا مشکل در کابل‌های SATA می‌توانند باعث شوند که یک بخش از فایل .MYI به‌درستی نوشته نشود. این نوع خرابی‌ها معمولاً با الگوی «چند جدول به‌طور هم‌زمان» شناسایی می‌شوند. اگر یک سکتور دیسک خراب شود، ممکن است چندین جدول که در آن ناحیه ذخیره شده‌اند هم‌زمان آسیب ببینند.

۴. باگ در MySQL یا MyISAM

هرچند نادر، اما نسخه‌های خاصی از MySQL (به‌خصوص نسخه‌های قدیمی‌تر از 5.6) باگ‌هایی در مدیریت فایل‌های MyISAM داشته‌اند که در شرایط خاص — مثل کوئری‌های سنگین هم‌زمان — باعث خرابی ایندکس می‌شده است. اگر از نسخه‌ای قدیمی استفاده می‌کنید، احتمال این سناریو بیشتر است.

۵. کپی فیزیکی نادرست فایل‌ها

یکی از اشتباهات رایج در میان توسعه‌دهندگان تازه‌کار، کپی کردن مستقیم فایل‌های .MYD و .MYI از یک سرور به سرور دیگر است، در حالی که سرور مبدأ در حال اجرا بوده. این کار باعث می‌شود فایل‌های ایندکس ناسازگار کپی شوند. این سناریو در سایت‌هایی که با پنل‌های مدیریت فایل مثل cPanel کار می‌کنند زیاد دیده می‌شود.

نشانه‌ها و علائم هشداردهنده

قبل از اینکه خطا به‌طور کامل ظاهر شود، معمولاً نشانه‌هایی وجود دارد که اگر به آن‌ها توجه کنید، می‌توانید از فاجعه جلوگیری کنید:

  • کندی ناگهانی کوئری‌ها: اگر جدولی که قبلاً سریع پاسخ می‌داد، ناگهان کند شود، ممکن است ایندکس آن در حال خراب شدن باشد.
  • خطاهای گاه‌به‌گاه در لاگ MySQL: خطاهایی مثل «Got error 127 from storage engine» یا «Key file is corrupted» در لاگ، پیش‌درآمدی برای خطای اصلی هستند.
  • مشکل در کوئری‌های خاص: اگر فقط کوئری‌هایی که از یک ایندکس خاص استفاده می‌کنند خطا بدهند، احتمال خرابی همان ایندکس بالاست.
  • افزایش فضای دیسک بدون دلیل: اگر فضای دیسک به‌طور غیرعادی در حال پر شدن است، ممکن است MySQL در حال تلاش برای بازسازی ایندکس‌های خراب باشد.

تشخیص دقیق: از کجا شروع کنیم؟

وقتی با این خطا مواجه می‌شوید، اولین کاری که باید بکنید این است که بفهمید کدام جدول و کدام ایندکس مشکل دارد. مسیر تشخیص را به ترتیب زیر طی کنید:

گام اول: پیدا کردن جدول مشکل‌دار

معمولاً پیام خطا نام جدول را در خود دارد. اگر در لاگ MySQL یا در خروجی PHP دنبال پیام خطا بگردید، معمولاً چیزی شبیه این پیدا می‌کنید:

Incorrect key file for table './wordpress/wp_options.MYI'; try to repair it

در اینجا wp_options نام جدول است و .MYI نشان می‌دهد که فایل ایندکس مشکل دارد.

گام دوم: بررسی سلامت جدول با CHECK TABLE

وارد محیط MySQL شوید و دستور زیر را اجرا کنید:

CHECK TABLE wp_options;

خروجی این دستور یکی از حالت‌های زیر است:

  • OK — جدول سالم است (احتمالاً مشکل از جای دیگری است)
  • Table is marked as crashed — جدول به‌عنوان خراب علامت‌گذاری شده
  • Incorrect key file — دقیقاً همان خطایی که با آن مواجه شده‌اید
  • Corrupt — جدول به‌شدت آسیب دیده

گام سوم: بررسی فایل‌های فیزیکی

با دسترسی SSH یا از طریق File Manager، به مسیر دیتابیس بروید و اندازه فایل‌های .MYD و .MYI را بررسی کنید. اگر اندازه فایل .MYI صفر باشد یا خیلی کوچک‌تر از حد انتظار باشد، احتمال خرابی شدید وجود دارد.

گام چهارم: بررسی لاگ خطای MySQL

فایل لاگ MySQL (معمولاً در /var/log/mysql/error.log یا در پنل هاست) را بررسی کنید. به دنبال خطاهایی مثل موارد زیر بگردید:

[ERROR] MyISAM: Key file for table 'wp_options' is corrupted
[ERROR] MyISAM: Table 'wp_options' is marked as crashed

این خطاها به شما می‌گویند که مشکل از کجا آمده و چقدر جدی است.

گام پنجم: تست با myisamchk (اختیاری)

اگر به SSH دسترسی دارید، می‌توانید از ابزار myisamchk استفاده کنید. این ابزار قدرتمندتر از CHECK TABLE است و اطلاعات دقیق‌تری می‌دهد:

myisamchk -e /var/lib/mysql/wordpress/wp_options

گزینه -e (extended check) یک بررسی عمیق انجام می‌دهد و هرگونه ناسازگاری در ایندکس‌ها را گزارش می‌کند.

راه‌حل‌های عملی و گام‌به‌گام

حالا که مشکل را تشخیص دادید، وقت درمان است. روش‌های درمان را به ترتیب از ساده‌ترین به پیچیده‌ترین مرتب کرده‌ام:

روش اول: REPAIR TABLE (ساده‌ترین و سریع‌ترین)

اگر جدول شما MyISAM است و به SSH دسترسی ندارید، این روش بهترین گزینه است:

REPAIR TABLE wp_options;

اگر این دستور جواب نداد، می‌توانید از گزینه‌های پیشرفته‌تر استفاده کنید:

REPAIR TABLE wp_options EXTENDED;

گزینه EXTENDED یک تعمیر عمیق‌تر انجام می‌دهد و ممکن است زمان بیشتری بگیرد. در جدول‌های بزرگ (مثل wp_posts با هزاران رکورد)، این دستور می‌تواند چند دقیقه طول بکشد.

نکته مهم: قبل از اجرای REPAIR TABLE، حتماً یک بکاپ از جدول بگیرید. در موارد نادر، تعمیر می‌تواند باعث از دست رفتن داده شود. برای بکاپ سریع:

CREATE TABLE wp_options_backup AS SELECT * FROM wp_options;

روش دوم: myisamchk (برای جدول‌های بزرگ)

اگر به SSH دسترسی دارید و جدول بزرگ است، myisamchk گزینه بهتری است. اول MySQL را متوقف کنید:

sudo systemctl stop mysql

سپس به مسیر دیتابیس بروید و دستور زیر را اجرا کنید:

myisamchk -r /var/lib/mysql/wordpress/wp_options

گزینه -r (recover) تلاش می‌کند ایندکس‌ها را بازسازی کند. اگر این روش جواب نداد، از گزینه -o (safe recover) استفاده کنید:

myisamchk -o /var/lib/mysql/wordpress/wp_options

برای جدول‌های خیلی بزرگ، می‌توانید از گزینه --sort-records هم استفاده کنید که فرآیند را سریع‌تر می‌کند.

روش سوم: بازسازی کامل جدول

اگر هیچ‌کدام از روش‌های بالا جواب نداد، باید جدول را به‌طور کامل بازسازی کنید. این روش در واقع جدول را از صفر می‌سازد و داده‌ها را از فایل .MYD بازیابی می‌کند:

-- ۱. ساخت یک جدول موقت با ساختار یکسان
CREATE TABLE wp_options_new LIKE wp_options;

-- ۲. کپی داده‌ها از جدول خراب به جدول جدید
INSERT INTO wp_options_new SELECT * FROM wp_options;

-- ۳. حذف جدول خراب
DROP TABLE wp_options;

-- ۴. تغییر نام جدول جدید
RENAME TABLE wp_options_new TO wp_options;

هشدار: این روش فقط زمانی جواب می‌دهد که فایل .MYD (داده‌ها) سالم باشد و فقط ایندکس خراب شده باشد. اگر داده‌ها هم آسیب دیده باشند، این روش ممکن است بخشی از داده‌ها را از دست بدهد.

روش چهارم: بازیابی از بکاپ

اگر هیچ‌کدام از روش‌های بالا جواب نداد و داده‌های حیاتی دارید، بهترین گزینه بازیابی از بکاپ است. اگر بکاپ ندارید، می‌توانید از ابزارهایی مثل mysqlcheck یا innodb_force_recovery (برای InnoDB) استفاده کنید. برای MyISAM، ابزار myisamchk با گزینه --force می‌تواند در مواردی که جدول به‌شدت خراب است، داده‌ها را بازیابی کند.

مهاجرت از MyISAM به InnoDB

اگر جدول‌های شما MyISAM هستند و چندین بار با این خطا مواجه شده‌اید، جدی‌ترین توصیه من این است: به InnoDB مهاجرت کنید. InnoDB از تراکنش‌ها (Transactions) پشتیبانی می‌کند و در برابر خرابی‌های ناگهانی بسیار مقاوم‌تر است.

مهاجرت از MyISAM به InnoDB در MySQL 5.6 به بعد بسیار ساده است:

ALTER TABLE wp_options ENGINE=InnoDB;

اما قبل از این کار، چند نکته را در نظر بگیرید:

  • حجم دیسک: InnoDB به فضای بیشتری نیاز دارد (به‌خاطر جداول تراکنشی و لاگ‌ها)
  • تنظیمات: پارامترهای innodb_buffer_pool_size و innodb_log_file_size را باید تنظیم کنید
  • زمان: برای جدول‌های بزرگ، این عملیات می‌تواند ساعت‌ها طول بکشد

اگر وردپرس دارید، از نسخه 5.5 به بعد، جدول‌های پیش‌فرض وردپرس به InnoDB ساخته می‌شوند. اما اگر سایت شما قدیمی است یا از افزونه‌هایی استفاده می‌کند که جدول‌های MyISAM می‌سازند، ممکن است هنوز جدول‌های MyISAM داشته باشید. برای بررسی:

SELECT TABLE_NAME, ENGINE 
FROM information_schema.TABLES 
WHERE TABLE_SCHEMA = 'database_name' 
AND ENGINE = 'MyISAM';

استراتژی‌های پیشگیری

جلوگیری از این خطا بسیار ارزان‌تر از درمان آن است. در تجربه‌ام، رعایت این نکات می‌تواند تا ۹۰٪ موارد را کاهش دهد:

۱. خاموشی اصولی سرور

همیشه از دستور mysqladmin shutdown یا systemctl stop mysql استفاده کنید. هرگز سرور را به‌صورت مستقیم ریست نکنید. اگر سرور شما UPS ندارد، حتماً یکی تهیه کنید.

۲. مانیتورینگ فضای دیسک

یک اسکریپت ساده بنویسید که هر ساعت فضای دیسک را بررسی کند و اگر به زیر ۱۰٪ رسید، به شما هشدار بدهد:

df -h | awk '$5+0 > 90 {print "Disk usage critical: " $5}'

۳. بکاپ منظم

یک برنامه بکاپ خودکار روزانه تنظیم کنید. بکاپ باید شامل فایل‌های .MYD، .MYI و .frm باشد. بهترین روش، استفاده از mysqldump است که یک فایل SQL متنی تولید می‌کند:

mysqldump -u root -p --all-databases > backup.sql

۴. بررسی دوره‌ای سلامت جدول‌ها

یک کرون‌جاب تنظیم کنید که هفتگی تمام جدول‌ها را بررسی کند:

mysqlcheck -u root -p --check --all-databases

اگر خروجی این دستور خطایی نشان داد، همان لحظه آن را برطرف کنید. این کار از تبدیل شدن یک مشکل کوچک به یک فاجعه جلوگیری می‌کند.

۵. استفاده از InnoDB

اگر هنوز روی MyISAM هستید، مهاجرت به InnoDB را در برنامه خود قرار دهید. InnoDB در برابر خرابی‌های ناگهانی بسیار مقاوم‌تر است و از تراکنش‌ها پشتیبانی می‌کند.

پرسش‌های پرتکرار درباره خطای Incorrect key file for table

آیا این خطا باعث از دست رفتن داده می‌شود؟

در بیشتر موارد، خیر. اگر فایل .MYD (داده‌ها) سالم باشد، با REPAIR TABLE یا myisamchk می‌توان ایندکس را بازسازی کرد. اما اگر خرابی به فایل .MYD هم سرایت کرده باشد، ممکن است بخشی از داده‌ها از دست برود. به همین دلیل، بکاپ منظم حیاتی است.

چرا این خطا فقط در جدول‌های خاصی رخ می‌دهد؟

جدول‌هایی که بیشتر در معرض نوشتن (INSERT/UPDATE) هستند، بیشتر در معرض خطرند. در وردپرس، جدول‌هایی مثل wp_options، wp_posts و wp_postmeta بیشترین احتمال خرابی را دارند.

آیا REPAIR TABLE روی جدول‌های InnoDB هم کار می‌کند؟

خیر. REPAIR TABLE فقط برای MyISAM طراحی شده است. برای InnoDB، باید از ابزارهای متفاوتی مثل innodb_force_recovery استفاده کنید.

آیا می‌توانم از این خطا جلوگیری کنم؟

بله. با رعایت نکات پیشگیری — خاموشی اصولی، مانیتورینگ دیسک، بکاپ منظم و مهاجرت به InnoDB — می‌توانید احتمال بروز این خطا را به حداقل برسانید.

آیا این خطا در MySQL 8 هم وجود دارد؟

بله، اما کمتر. MySQL 8 به‌طور پیش‌فرض از InnoDB استفاده می‌کند و MyISAM را فقط به‌عنوان یک موتور قدیمی نگه داشته است. اگر در MySQL 8 روی MyISAM کار می‌کنید، احتمال بروز این خطا بسیار کمتر است.

آیا می‌توانم بدون SSH این خطا را برطرف کنم؟

بله. اگر به phpMyAdmin دسترسی دارید، می‌توانید از تب Operations استفاده کنید. در آنجا گزینه‌ای به نام «Repair table» وجود دارد. اما برای جدول‌های بزرگ، این روش ممکن است با محدودیت زمانی مواجه شود.

کالبدشکافی فنی: درون فایل .MYI چه خبر است؟

برای درک عمیق این خطا، باید بدانید فایل .MYI چطور ساخته می‌شود. هر فایل ایندکس MyISAM از یک هدر ۲۴ بایتی شروع می‌شود که شامل اطلاعات زیر است:

  • شماره نسخه فرمت (فرمت ۰ یا ۱): نسخه ساختار فایل ایندکس
  • طول هدر: همیشه ۲۴ بایت
  • طول هر رکورد ایندکس: بستگی به نوع ایندکس دارد
  • تعداد کلیدها: تعداد کلیدهای تعریف‌شده در جدول
  • طول هر صفحه: معمولاً ۱۰۲۴ بایت

وقتی MySQL می‌خواهد یک رکورد را بخواند، این مراحل را طی می‌کند:

  1. هدر فایل .MYI را می‌خواند و شماره نسخه فرمت را بررسی می‌کند.
  2. اگر نسخه فرمت با آنچه MySQL انتظار دارد هم‌خوانی نداشته باشد، خطای «Incorrect key file» را تولید می‌کند.
  3. سپس طول هر رکورد ایندکس را می‌خواند و با طول مورد انتظار مقایسه می‌کند.
  4. اگر طول رکورد ایندکس با آنچه MySQL انتظار دارد فرق کند، باز هم خطا تولید می‌شود.
  5. در نهایت، MySQL از طریق ایندکس به فایل .MYD مراجعه می‌کند و داده‌های واقعی را می‌خواند.

طول رکورد ایندکس به نوع ستون‌های ایندکس‌شده بستگی دارد. اگر ستون‌های جدول تغییر کنند — مثلاً یک ستون VARCHAR(255) به VARCHAR(500) تغییر کند — طول رکورد ایندکس هم تغییر می‌کند. اما فایل .MYI قدیمی همچنان طول قدیمی را در هدر خود نگه می‌دارد. این ناسازگاری باعث خطا می‌شود.

ابزارهای تعمیر دیتابیس: کدام را انتخاب کنیم؟

در طول سال‌ها، ابزارهای مختلفی را برای تعمیر دیتابیس امتحان کرده‌ام. هر کدام نقاط قوت و ضعف خودشان را دارند:

۱. mysqlcheck

ابزار خط فرمانی MySQL که برای بررسی و تعمیر جدول‌ها طراحی شده است. ساده‌ترین راه استفاده:

mysqlcheck -u root -p --auto-repair --all-databases

گزینه --auto-repair به‌طور خودکار جدول‌های خراب را تعمیر می‌کند. این ابزار برای تعمیر دوره‌ای خوب است، اما برای خرابی‌های پیچیده کافی نیست.

۲. myisamchk

قدرتمندترین ابزار برای تعمیر جدول‌های MyISAM. اما باید MySQL را متوقف کنید. گزینه‌های مفید:

myisamchk -r table_name     # تعمیر سریع
myisamchk -o table_name     # تعمیر ایمن
myisamchk -e table_name     # بررسی عمیق
myisamchk --force table_name # اجبار به تعمیر

۳. phpMyAdmin

اگر به SSH دسترسی ندارید، phpMyAdmin گزینه مناسبی است. از تب Operations می‌توانید گزینه‌های Repair table و Check table را اجرا کنید. محدودیت اصلی این ابزار، timeout سرور است — برای جدول‌های بزرگ ممکن است عملیات نیمه‌کاره رها شود.

۴. افزونه‌های وردپرس

افزونه‌هایی مثل WP-DBManager و WP-Sweep می‌توانند جدول‌های وردپرس را تعمیر کنند. اما این افزونه‌ها معمولاً از همان دستور REPAIR TABLE استفاده می‌کنند و محدودیت‌های آن را دارند.

چه زمانی باید از یک متخصص کمک بگیریم؟

اگر با این شرایط مواجه شدید، بهتر است از یک متخصص دیتابیس کمک بگیرید:

  • چندین جدول هم‌زمان خراب شده‌اند: این نشانه‌ای از یک مشکل سخت‌افزاری جدی است.
  • REPAIR TABLE و myisamchk هر دو جواب نداده‌اند: ممکن است خرابی فراتر از ایندکس باشد.
  • داده‌های حیاتی دارید و بکاپ ندارید: دستکاری دیتابیس خراب بدون بکاپ، می‌تواند فاجعه‌بار باشد.
  • سرور شما به‌طور مکرر خراب می‌شود: این نشانه‌ای از یک مشکل ساختاری است که باید ریشه‌ای حل شود.
  • خطاهای سخت‌افزاری در لاگ‌ها می‌بینید: خطاهایی مثل I/O error یا Bad sector نشانه‌های جدی هستند.

استراتژی بکاپ برای جدول‌های MyISAM

بکاپ‌گیری از جدول‌های MyISAM با InnoDB تفاوت دارد. در MyISAM، چون هر جدول از سه فایل جداگانه تشکیل شده، باید هر سه فایل را بکاپ بگیرید. روش‌های بکاپ:

۱. mysqldump (توصیه شده)

mysqldump -u root -p --all-databases --single-transaction > backup.sql

گزینه --single-transaction برای InnoDB است. برای MyISAM، باید از --lock-tables استفاده کنید:

mysqldump -u root -p --all-databases --lock-tables > backup.sql

۲. کپی فیزیکی فایل‌ها

اگر MySQL متوقف است، می‌توانید فایل‌های .MYD، .MYI و .frm را کپی کنید. اما این روش فقط زمانی امن است که MySQL کاملاً متوقف باشد.

۳. بکاپ از طریق phpMyAdmin

از تب Export می‌توانید یک فایل SQL دانلود کنید. برای جدول‌های بزرگ، ممکن است با محدودیت حجم مواجه شوید.

مطالعه موردی: نجات یک فروشگاه ووکامرسی

چند سال پیش، یک فروشگاه ووکامرسی با ۵۰۰۰ محصول و روزانه ۲۰۰ سفارش با این خطا مواجه شد. سایت روی یک سرور مجازی با ۴ گیگابایت رم اجرا می‌شد و جدول‌های آن — به‌دلیل استفاده از یک افزونه قدیمی — MyISAM بودند.

علائم:

  • صفحه محصولات خطای «Incorrect key file for table wp_postmeta» نشان می‌داد
  • صفحه سفارشات هم گاهی خطا می‌داد
  • لاگ MySQL پر از خطاهای Got error 127 بود

تشخیص:

با اجرای CHECK TABLE مشخص شد که سه جدول (wp_postmeta، wp_options و wp_woocommerce_order_items) خراب هستند. فایل .MYI جدول wp_postmeta فقط ۱ کیلوبایت بود — در حالی که باید چند مگابایت باشد.

درمان:

  1. ابتدا از کل دیتابیس بکاپ گرفتم.
  2. MySQL را متوقف کردم.
  3. با myisamchk -r سه جدول را تعمیر کردم.
  4. بعد از راه‌اندازی مجدد، خطاها برطرف شدند.
  5. در نهایت، تمام جدول‌ها را به InnoDB مهاجرت دادم.

درس‌آموخته:

استفاده از افزونه‌های قدیمی که جدول‌های MyISAM می‌سازند، یک ریسک جدی است. اگر ووکامرس دارید، حتماً مطمئن شوید که تمام جدول‌ها InnoDB هستند.

سخن آخر: ریشه‌یابی، نه تعمیر مکرر

خطای «Incorrect key file for table» یک هشدار جدی است. اگر این خطا را مکرراً می‌بینید، بدانید که تعمیر مکرر، درمان نیست — فقط مسکن است. ریشه مشکل در جایی دیگر است: شاید سخت‌افزار، شاید تنظیمات MySQL، شاید هم استفاده از یک موتور قدیمی مثل MyISAM.

توصیه نهایی من این است: اگر هنوز روی MyISAM هستید، مهاجرت به InnoDB را در اولویت قرار دهید. اگر روی InnoDB هستید و این خطا را می‌بینید، به سراغ بررسی سلامت دیسک و سخت‌افزار بروید. و در هر حال، بکاپ منظم را فراموش نکنید — بکاپ، بیمه‌نامه‌ای است که هزینه‌اش را یک بار می‌پردازید، اما در روز حادثه، ارزشش را چند برابر برمی‌گرداند.

اگر این مشکل را در پروژه‌ای تجربه کرده‌اید و راه‌حل متفاوتی پیدا کرده‌اید، خوشحال می‌شوم تجربه‌تان را بشنوم. به‌خصوص اگر با جدول‌های بزرگ (چند گیگابایتی) کار کرده‌اید و روش خاصی برای تعمیر سریع‌تر پیدا کرده‌اید — این نوع تجربه‌ها برای خواننده بعدی از هر مقاله‌ای ارزشمندتر است.