چرا خطای Packet too large در MySQL رخ می‌دهد و چگونه آن را اصولی برطرف کنیم؟

مقدمه

چند سال پیش، روی یک پروژه ووکامرسی با حدود ۸۰ هزار محصول درگیر بودم که مدیر سایت می‌خواست یک فایل CSV هشت‌مگابایتی را از طریق پنل وردپرس آپلود کند. هر بار که ایمپورت را می‌زد، با یک پیام عجیب مواجه می‌شد: «MySQL server has gone away» یا گاهی «Packet too large». من اول فکر کردم مشکل از هاست است — اما بعد از بررسی لاگ MySQL، فهمیدم ریشه ماجرا در یک پارامتر پنهان به نام max_allowed_packet بود که مقدار پیش‌فرضش در آن هاست، فقط یک مگابایت بود.

این خطا در تجربه من از آن دسته خطاهایی است که همیشه هم به‌عنوان «Packet too large» ظاهر نمی‌شود؛ گاهی با پیام‌های دیگر همراه است و همین باعث می‌شود که تشخیص آن زمان‌بر شود. در این مقاله می‌خواهم دقیقاً بگویم این خطا از کجا می‌آید، چه تفاوتی با خطاهای هم‌خانواده دارد، و چه راهکارهایی برای حل ریشه‌ای آن وجود دارد.

خطای Packet too large دقیقاً چیست؟

پیام «Packet too large» (کد خطای 1153 در MySQL) یعنی یکی از بسته‌هایی که کلاینت به سرور فرستاده (یا سرور به کلاینت فرستاده) از سقف مجاز max_allowed_packet بزرگ‌تر بوده است. MySQL برای هر ارتباط یک سقف اندازه بسته تعریف می‌کند که به دلایل امنیتی و عملکردی، از پذیرش بسته‌های بزرگ‌تر خودداری می‌کند.

پیام کامل خطا معمولاً به یکی از شکل‌های زیر ظاهر می‌شود:

ERROR 1153 (08S01): Got a packet bigger than 'max_allowed_packet' bytes

یا شکل دیگری که در محیط‌های وردپرسی شایع‌تر است:

ERROR 2006 (HY000): MySQL server has gone away

نکته جالب این است که در بسیاری از مواقع، وقتی بسته‌ای از سقف رد می‌شود، MySQL نه با پیام صریح Packet too large، بلکه با یک قطع ساده اتصال پاسخ می‌دهد. این رفتار عمدی است: MySQL ترجیح می‌دهد به‌جای پردازش یک بسته بزرگ و پرخطر، اتصال را ببندد. به همین دلیل، اگر خطای Lost connection to MySQL server را می‌بینید و در لاگ MySQL هیچ نشانه دیگری نیست، اولین مشکوک باید همین max_allowed_packet باشد.

یک تمایز مهم: خطای Packet too large از جنس «مشکل شبکه» نیست، از جنس «مشکل قرارداد» است. یعنی MySQL و کلاینت بر سر اندازه بسته‌ها به توافق نرسیده‌اند. برای مطالعه بیشتر درباره پروتکل MySQL، ویکی‌پدیا نقطه شروع خوبی است.

Packet too large یعنی قرارداد بین کلاینت و سرور شکسته شده؛ سؤال درست این است «کدام بسته از قرارداد رد شد»، نه «چرا MySQL سختگیر است».

پنج ریشه اصلی این خطا

در تجربه‌ام، این خطا تقریباً همیشه یکی از پنج ریشه زیر را دارد. هر کدام امضای خاص خودش را دارد و در موقعیت متفاوتی رخ می‌دهد:

۱. مقدار کوچک max_allowed_packet

شایع‌ترین علت. مقدار پیش‌فرض این پارامتر در نسخه‌های قدیمی MySQL فقط یک مگابایت بود. حتی در نسخه‌های جدید (MySQL 5.7 و 8)، مقدار پیش‌فرض ۶۴ مگابایت است، اما بسیاری از هاست‌های اشتراکی آن را به یک یا چهار مگابایت کاهش می‌دهند تا از مصرف بی‌رویه منابع جلوگیری کنند. در این حالت، حتی ذخیره یک برگه وردپرس با محتوای سنگین می‌تواند به این خطا منجر شود.

SHOW VARIABLES LIKE 'max_allowed_packet';
-- خروجی: 1048576 یعنی فقط ۱ مگابایت

۲. ایمپورت فایل SQL بزرگ

وقتی فایل SQL یک دیتابیس را با ابزارهایی مثل phpMyAdmin ایمپورت می‌کنید، هر دستور INSERT جداگانه به‌عنوان یک بسته ارسال می‌شود. اگر یکی از دستورات INSERT بزرگ‌تر از سقف باشد — مثلاً یک INSERT با ۵۰ هزار ردیف در یک دستور — MySQL آن را رد می‌کند. این حالت در ایمپورت‌های Backup وردپرس و ووکامرس بسیار شایع است.

۳. Export و گزارش‌گیری سنگین

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

۴. ذخیره‌سازی داده‌های حجیم در یک ردیف

اگر ستونی از نوع LONGTEXT یا LONGBLOB باشد و شما تلاش کنید یک رشته چند مگابایتی (مثلاً محتوای Base64 یک تصویر) را در آن ذخیره کنید، ممکن است همین خطا رخ دهد. این حالت در پروژه‌هایی که از افزونه‌های ذخیره‌سازی تصویر در دیتابیس استفاده می‌کنند، دیده می‌شود.

۵. تنظیم نامتوازن سمت کلاینت و سرور

گاهی مقدار max_allowed_packet سرور ۶۴ مگابایت است، اما کتابخانه PHP فقط تا ۱۶ مگابایت به‌عنوان سقف خودش می‌داند. در این حالت، اتصال با یک مقدار مذاکره می‌شود و اگر بسته بزرگ‌تر باشد، خطا رخ می‌دهد حتی اگر سرور آماده پذیرش باشد. این حالت در پروژه‌هایی که از PDO یا MySQLi با تنظیمات سفارشی استفاده می‌کنند، شایع است.

نشانه‌ها و علائم تشخیص

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

• شکست در ایمپورت‌های بزرگ: اگر ایمپورت فایل SQL در نیمه راه متوقف می‌شود، بدون اینکه خطای مشخصی نمایش داده شود، احتمالاً همین خطاست.
• خطای صفحه سفید در ذخیره برگه: اگر برگه‌های سنگین وردپرس هنگام ذخیره، پیام خطا می‌دهند، احتمالاً اندازه محتوا از سقف بسته رد شده است.
• Export ناقص: اگر فایل SQL خروجی از یک دیتابیس بزرگ، حاوی بخشی از داده‌ها نباشد، احتمالاً Export در نیمه راه قطع شده است.
• پیام‌های متناقض در لاگ: گاهی اوقات پیام MySQL server has gone away در لاگ می‌بینید اما دلیلش همان Packet too large بوده است.
• کندی غیرعادی در حین اجرای کوئری‌های سنگین: اگر کوئری‌های سنگین به‌جای پاسخ سریع، باعث قطع ارتباط می‌شوند، احتمالاً به سقف بسته نزدیک شده‌اید.

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

برای تشخیص دقیق، ترتیب زیر را در تجربه‌ام مفید یافته‌ام:

گام اول: بررسی مقدار فعلی پارامتر

SHOW VARIABLES LIKE 'max_allowed_packet';

اگر مقدار کمتر از ۱۶ مگابایت بود، به آن مشکوک شوید. برای مقایسه، مقدار پیش‌فرض MySQL 8 برابر ۶۴ مگابایت است و مقدار مناسب برای بیشتر پروژه‌های وردپرسی، حداقل ۳۲ مگابایت.

گام دوم: بررسی لاگ MySQL

grep -i "packet" /var/log/mysql/error.log | tail -20

به دنبال پیام‌هایی مثل موارد زیر بگردید:

[Warning] Got a packet bigger than 'max_allowed_packet' bytes
[Note] Aborted connection 42 to db: 'wordpress' user: 'root' (Got an error reading communication packets)

گام سوم: شناسایی کوئری مقصر

با فعال‌سازی General Log، می‌توانید کوئری‌هایی که باعث خطا می‌شوند را شکار کنید:

SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/tmp/mysql-general.log';

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

گام چهارم: بررسی اندازه محتوا

اگر خطا در ذخیره یک برگه وردپرس رخ می‌دهد، حجم ستون post_content آن برگه را در دیتابیس بررسی کنید:

SELECT ID, LENGTH(post_content) AS content_size 
FROM wp_posts 
ORDER BY content_size DESC 
LIMIT 10;

این کوئری، ۱۰ پست با بزرگ‌ترین محتوا را نشان می‌دهد. اگر اندازه‌شان نزدیک به سقف بسته است، مقصر پیدا شده است.

گام پنجم: مقایسه سمت کلاینت و سرور

اگر از PDO یا MySQLi استفاده می‌کنید، مطمئن شوید که مقدار max_allowed_packet در سمت کلاینت هم به‌درستی تنظیم شده است. در PDO، این مقدار از سرور خوانده می‌شود، اما در بعضی پیکربندی‌های خاص، نیاز به تنظیم دستی دارد.

تفاوت با خطاهای مشابه

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

دو نکته ظریف در این جدول وجود دارد. اول، خطای Packet too large و Lost connection to MySQL server اغلب از یک ریشه تغذیه می‌کنند، اما نقطه نمایش متفاوت است. دوم، خطای Query execution was interrupted ناشی از یک تصمیم زمانی است، در حالی که Packet too large ناشی از یک محدودیت فیزیکی است. تشخیص درست این تفاوت‌ها، اولین قدم در حل صحیح است.

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

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

راه‌حل فوری: افزایش max_allowed_packet

ساده‌ترین راه‌حل، افزایش پارامتر سرور است. در سطح session:

SET SESSION max_allowed_packet = 67108864;  -- ۶۴ مگابایت

در سطح سرور (نیاز به دسترسی ادمین):

SET GLOBAL max_allowed_packet = 67108864;

یا در فایل پیکربندی برای اعمال دائمی:

[mysqld]
max_allowed_packet = 64M
[mysqldump]
max_allowed_packet = 64M

نکته مهم: تنظیم این پارامتر در بخش [mysqldump] هم ضروری است، چون خود mysqldump یک کلاینت جداگانه است و سقف خودش را دارد.

راه‌حل کوتاه‌مدت: تقسیم کوئری‌ها

اگر به هر دلیلی نمی‌توانید پارامتر سرور را افزایش دهید — مثلاً روی هاست اشتراکی هستید — باید کوئری‌ها را تقسیم کنید. سه تکنیک اصلی:

تقسیم INSERTهای بزرگ: به‌جای یک INSERT با ۵۰ هزار ردیف، آن را به ۵۰ INSERT با ۱٫۰۰۰ ردیف تقسیم کنید. این کار را می‌توانید در کد PHP به‌سادگی با array_chunk() انجام دهید:

$chunks = array_chunk($rows, 1000);
foreach ($chunks as $chunk) {
    $values = implode(',', array_map(function($row) {
        return '(' . implode(',', array_map('quote', $row)) . ')';
    }, $chunk));
    $pdo->exec("INSERT INTO wp_posts VALUES $values");
}

استفاده از LIMIT در گزارش‌ها: اگر گزارش شما فقط ۱۰۰۰ ردیف آخر را نشان می‌دهد، چرا باید کل جدول را از دیتابیس بکشید؟ افزودن LIMIT 1000 به کوئری، حجم بسته را کاهش می‌دهد. این موضوع در گزارش‌های ووکامرس که روی جدول wp_postmeta کار می‌کنند، بسیار مهم است. برای مطالعه بیشتر، مقاله بهینه‌سازی دیتابیس ووکامرس را ببینید.

استفاده از LOAD DATA INFILE: برای ایمپورت داده‌های حجیم، به‌جای INSERT، از LOAD DATA INFILE استفاده کنید که به‌صورت مستقیم فایل CSV را از دیسک می‌خواند و نیازی به ارسال بسته از طرف کلاینت ندارد:

LOAD DATA INFILE '/path/to/data.csv'
INTO TABLE wp_posts
FIELDS TERMINATED BY ',' 
ENCLOSED BY '"' 
LINES TERMINATED BY '\n'
IGNORE 1 ROWS;

راه‌حل ساختاری: بازطراحی برای داده‌های حجیم

اگر پروژه‌ای دارید که مرتب با داده‌های حجیم سر و کار دارد، باید معماری را بازبینی کنید:

• ذخیره‌سازی فایل در فایل‌سیستم، نه در دیتابیس: تصاویر، PDFها و فایل‌های حجیم را در دیسک ذخیره کنید، نه در ستون‌های BLOB. دیتابیس برای داده‌های ساختاریافته طراحی شده، نه برای فایل‌های باینری.
• استفاده از جداول واسط: به‌جای ذخیره یک رشته چند مگابایتی در یک ردیف، آن را به ردیف‌های کوچک‌تر در یک جدول واسط تقسیم کنید.
• بایگانی داده‌های قدیمی: داده‌هایی که سال‌ها در جدول‌های اصلی مانده‌اند و کمتر از آن‌ها استفاده می‌شود، می‌توانند به جدول بایگانی منتقل شوند تا حجم کوئری‌های جاری کاهش یابد. راهنمای بکاپ‌گیری اصولی در استراتژی بکاپ MySQL آمده است.

راه‌حل مقطعی: تنظیم در سطح ابزار Import

اگر با ابزارهایی مثل mysqldump و mysql کار می‌کنید، می‌توانید در همان لحظه ایمپورت، پارامتر را تنظیم کنید:

mysql --max_allowed_packet=64M -u root -p wordpress < backup.sql

در سمت Export:

mysqldump --max_allowed_packet=64M -u root -p wordpress > backup.sql

این راه‌حل به‌ویژه در مهاجرت‌های بین سرورها کاربرد دارد — همان موضوعی که در مهاجرت سایت به هاست جدید مفصل بررسی کرده‌ام.

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

پیشگیری از این خطا، نیازمند نگاه معماری است. در تجربه‌ام، رعایت این نکات بیشترین بازدهی را داشته:

۱. تحلیل منظم اندازه‌های غیرعادی

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

SELECT 'wp_posts' AS tbl, ID, LENGTH(post_content) AS size 
FROM wp_posts ORDER BY size DESC LIMIT 5
UNION ALL
SELECT 'wp_postmeta', meta_id, LENGTH(meta_value) 
FROM wp_postmeta ORDER BY 3 DESC LIMIT 5;

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

۲. حذف ردیف‌های زائد

در وردپرس، جدول wp_options اغلب محل تجمع ردیف‌های حجیم است: logهای پاک‌نشده، داده‌های کش‌شده، و تنظیمات افزونه‌هایی که سال‌ها پیش حذف شده‌اند. پاکسازی دوره‌ای این جدول، حجم کوئری‌ها را به‌شدت کاهش می‌دهد — همان‌طور که در مقاله پاکسازی دیتابیس وردپرس توضیح دادم.

۳. ایندکس‌گذاری هوشمند

بخشی از خطای Packet too large ناشی از کوئری‌هایی است که به‌خاطر نبود ایندکس، مجبور به اسکن کل جدول می‌شوند و نتایج بزرگی برمی‌گردانند. روش اصولی ایندکس‌گذاری را در مقاله ایندکس‌گذاری در دیتابیس نوشته‌ام.

۴. پایش مستمر لاگ MySQL

grep -i "packet" /var/log/mysql/error.log | wc -l

اگر این عدد در طول هفته صعودی است، به‌موقع به سراغ تنظیمات بروید.

۵. هماهنگی پارامترها

پارامترهای مرتبط را همیشه با هم تنظیم کنید: max_allowed_packet، wait_timeout، و net_read_timeout. اگر یکی را افزایش دهید و دیگری را کوچک نگه دارید، خطاهای عجیب و غریب ظاهر می‌شوند. راهنمای کامل این پارامترها در انتخاب هاست آمده است.

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

پرسش‌های پرتکرار درباره Packet Too Large

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

در بیشتر موارد خیر، چون MySQL قبل از ذخیره‌سازی بسته را رد می‌کند و هیچ تغییری روی داده‌ها اعمال نمی‌شود. اما در ایمپورت‌های نیمه‌کاره، ممکن است بخشی از داده‌ها وارد شده و بخشی نشده باشد. به همین دلیل، قبل از ایمپورت‌های بزرگ، حتماً بکاپ بگیرید.

مقدار مناسب max_allowed_packet برای وردپرس چقدر است؟

برای اکثر سایت‌های وردپرسی، ۱۶ تا ۳۲ مگابایت کافی است. برای فروشگاه‌های ووکامرس با ایمپورت‌های حجیم، ۶۴ مگابایت توصیه می‌شود. مقدار بیشتر از ۲۵۶ مگابایت معمولاً توجیه فنی ندارد و می‌تواند به مصرف بی‌رویه حافظه منجر شود.

تفاوت این خطا با Lost connection چیست؟

خطای Packet too large صریح است و در لاگ MySQL ثبت می‌شود، اما خطای Lost connection می‌تواند ناشی از دلایل مختلفی باشد — از جمله همین بسته بزرگ. در عمل، اگر Lost connection بدون دلیل مشخصی مکرر رخ می‌دهد، به سراغ max_allowed_packet بروید.

آیا می‌توانم این پارامتر را روی هاست اشتراکی تغییر دهم؟

در سطح session بله، اما در سطح سرور معمولاً خیر. اگر هاست شما اجازه تنظیم ندارد، باید به سراغ تقسیم کوئری‌ها و استفاده از LOAD DATA INFILE بروید — همان‌طور که در بخش راه‌حل‌ها توضیح دادم.

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

بله، اما مقدار پیش‌فرض max_allowed_packet در MySQL 8 برابر ۶۴ مگابایت است، در حالی که در نسخه‌های 5.6 و 5.7 حدود ۴ مگابایت بود. بنابراین، احتمال بروز این خطا در MySQL 8 کمتر است — اما اگر هاست شما مقدار را کم کرده باشد، همچنان رخ می‌دهد.

چطور بفهمم کدام کوئری مقصر است؟

با فعال‌سازی General Log و پایش لاگ در لحظه بروز خطا، کوئری مقصر قابل شناسایی است. اگر از وردپرس استفاده می‌کنید، افزونه Query Monitor هم می‌تواند کوئری‌های سنگین را در زمان واقعی نشان دهد.

آیا این خطا فقط در ایمپورت رخ می‌دهد؟

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

کالبدشکافی فنی: پروتکل MySQL چطور بسته‌ها را مدیریت می‌کند؟

برای درک عمیق این خطا، باید بدانید پروتکل MySQL چطور داده‌ها را بین کلاینت و سرور جابه‌جا می‌کند. پروتکل ارتباطی MySQL یک پروتکل لایه‌ای است که از دو نوع بسته استفاده می‌کند:

1. بسته‌های کنترلی (Control Packets): برای مدیریت اتصال و اجرای کوئری‌ها
2. بسته‌های داده (Data Packets): برای انتقال داده‌های واقعی

هر بسته داده در MySQL از یک هدر ۴ بایتی شروع می‌شود که ۳ بایت اول اندازه بسته (حداکثر ۱۶ مگابایت در هر بسته) و بایت چهارم، شماره ترتیب است. اگر داده‌ای بیش از ۱۶ مگابایت باشد، MySQL آن را به چند بسته تقسیم می‌کند و به‌ترتیب ارسال می‌کند.

پارامتر max_allowed_packet در واقع سقف کل داده‌ای است که MySQL قبول می‌کند — حتی اگر این داده به چند بسته کوچک‌تر تقسیم شده باشد. یعنی اگر یک کوئری ۵۰ مگابایتی بفرستید که در ۵ بسته ۱۰ مگابایتی تقسیم شده باشد، MySQL آن را رد می‌کند چون مجموع از سقف تعریف‌شده بزرگ‌تر است.

نکته مهم و کمتر شناخته‌شده: این پارامتر در دو طرف ارتباط قابل تنظیم است. اگر سمت سرور ۶۴ مگابایت باشد و سمت کلاینت ۸ مگابایت، مقدار مؤثر برابر ۸ مگابایت است — یعنی کم‌ترین مقدار، برنده مذاکره است. به همین دلیل، اگر با خطای Packet too large مواجه شدید، باید هر دو طرف را بررسی کنید.

نکته دوم: مکانیزم تقسیم بسته (Packet Splitting) باعث می‌شود که حتی داده‌های بزرگ‌تر از ۱۶ مگابایت هم قابل ارسال باشند، اما سقف نهایی را همان max_allowed_packet تعیین می‌کند. اگر در لاگ MySQL پیام Multi-packet error دیدید، یعنی این مکانیزم با محدودیت برخورد کرده است.

برای مطالعه بیشتر درباره لایه‌های ذخیره‌سازی و موتورهای MySQL، مقاله تفاوت InnoDB و MyISAM و همچنین تراکنش‌ها در MySQL را توصیه می‌کنم.

نقش هاست اشتراکی در بروز این خطا

بیشتر مواردی که این خطا را در هاست اشتراکی دیده‌ام، سه علت مشترک داشته‌اند:

۱. مقدار پیش‌فرض پایین در سیاست هاست

بسیاری از هاست‌های اشتراکی، مقدار max_allowed_packet را به‌طور پیش‌فرض روی ۱ یا ۴ مگابایت تنظیم می‌کنند تا از سوءاستفاده یک سایت جلوگیری کنند. اما این تصمیم، بدون توجه به نیاز واقعی سایت‌های وردپرسی گرفته می‌شود و باعث می‌شود که حتی عملیات معمولی مثل ذخیره یک برگه با محتوای چند مگابایتی، خطا بدهد.

راهکار: با یک تیکت به پشتیبانی هاست، درخواست افزایش این پارامتر به ۳۲ یا ۶۴ مگابایت را بدهید. در پروژه‌های واقعی، بیشتر هاست‌های حرفه‌ای این درخواست را در سطح سرور اعمال می‌کنند. اگر هاست شما پاسخ مثبت نمی‌دهد، به سراغ گزینه‌های بعدی بروید.

۲. محدودیت منابع CPU و RAM

افزایش max_allowed_packet نیازمند RAM آزاد در سرور است. اگر هاست شما منابع کمی دارد، افزایش این پارامتر می‌تواند به مصیبت بزرگ‌تری منجر شود — مثلاً فروریختن سرور در ساعات پیک. بنابراین، هاست‌های اشتراکی ترجیح می‌دهند این پارامتر را کوچک نگه دارند. راهکار اصولی این است که کوئری‌های خود را کوچک‌تر کنید — همان روشی که در کاهش مصرف منابع هاست توضیح دادم.

۳. Statement Timeout اجباری

بخشی از خطاهای Packet too large در هاست اشتراکی، در واقع ناشی از یک Statement Timeout اجباری است. اگر کوئری شما به خاطر حجم بزرگ کند شود و از سقف زمانی رد شود، MySQL ممکن است آن را با پیام Packet too large نشان دهد. بررسی این پارامتر با دستور SHOW VARIABLES LIKE 'max_execution_time' انجام می‌شود — همان‌طور که در خطای Query execution was interrupted بررسی کرده‌ام.

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

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

یک فروشگاه ووکامرسی با حدود ۸۰ هزار محصول و ۲۰ هزار مشتری، می‌خواست از سیستم قبلی به ووکامرس مهاجرت کند. تیم پیاده‌سازی، دیتابیس را با mysqldump Export کرده بود و می‌خواست با mysql روی سرور جدید Import کند. اما هر بار، بعد از حدود ۳ دقیقه، ایمپورت با خطا قطع می‌شد.

علائم:

• خطا فقط در جدول wp_postmeta رخ می‌داد
• بعد از خطا، MySQL همچنان فعال بود، اما نیمی از ردیف‌ها ایمپورت نشده بودند
• لاگ MySQL پیام Got a packet bigger than 'max_allowed_packet' bytes نشان می‌داد

تشخیص:

با بررسی، مشخص شد که فایل SQL در بعضی دستورات INSERT، حدود ۸۰ مگابایت حجم داشت — چون ابزار مهاجرت، داده‌های هر دسته را در یک INSERT واحد می‌فرستاد. سرور جدید، مقدار max_allowed_packet را روی ۱۶ مگابایت تنظیم کرده بود. در نتیجه، هر دستور INSERT بزرگ، رد می‌شد.

درمان:

1. ابتدا با استفاده از ابزار sed، فایل SQL را طوری تقسیم کردم که هر INSERT حداکثر ۵ مگابایت باشد.
2. سپس ایمپورت را با تنظیم صریح --max_allowed_packet=64M در هر دو سمت اجرا کردم.
3. در نهایت، با تغییر روش مهاجرت به استفاده از LOAD DATA INFILE، زمان ایمپورت از ۳ ساعت به ۴۵ دقیقه کاهش یافت.

درس‌آموخته:

مشکل فقط افزایش پارامتر نبود؛ الگوی Export هم مقصر بود. ابزارهای Export باید طوری پیکربندی شوند که هر INSERT حداکثر چند مگابایت باشد. این کار را می‌توان با گزینه --extended-insert=FALSE در mysqldump انجام داد — هرچند این گزینه حجم فایل را بیشتر می‌کند، اما ایمپورت را مقاوم‌تر می‌سازد. اگر می‌خواهید درباره استراتژی بکاپ‌گیری بیشتر بدانید، مقاله استراتژی بکاپ MySQL را ببینید.

برای مطالعه موردی مشابه درباره عیب‌یابی سیستماتیک دیتابیس، مقاله تأثیر دیتابیس بر سرعت سایت را توصیه می‌کنم. همچنین اگر در پی مقایسه عمیق موتورهای ذخیره‌سازی هستید، تفاوت InnoDB و MyISAM نقطه شروع خوبی است.

خط پایان: بسته‌های کوچک، پروژه‌های بزرگ

خطای «Packet too large» در نگاه اول ترسناک است، اما در واقع یک علامت مرزی است: MySQL به شما می‌گوید که داده‌ای که فرستادید از محدوده‌ای که می‌تواند بپذیرد بزرگ‌تر است. سؤال درست این نیست «چطور این مرز را جابه‌جا کنم»، بلکه این است «چرا داده‌ای به این بزرگی باید از این مرز عبور کند».

از تجربه‌ام، چهار اصل عملی بیشترین بازدهی را داشته‌اند: اول، مقدار max_allowed_packet را در همان روز راه‌اندازی پروژه بررسی و تنظیم کنید — نه زمانی که به خطا خورده‌اید. دوم، کوئری‌های بزرگ را به قطعات کوچک تقسیم کنید، به‌خصوص در ایمپورت و ذخیره‌سازی داده‌های حجیم. سوم، برای انتقال‌های بزرگ از LOAD DATA INFILE استفاده کنید که نیازمند عبور از سقف بسته نیست. چهارم، به‌جای ذخیره فایل‌های باینری در دیتابیس، آن‌ها را در فایل‌سیستم نگه دارید.

در نهایت، اگر روی هاست اشتراکی هستید، باید بپذیرید که یک سقف سخت‌افزاری وجود دارد که نمی‌توانید آن را تغییر دهید. در این حالت، تنها راه‌حل واقعی، تقسیم کوئری‌ها و بازطراحی الگوی داده است. اگر هم خودتان سرور اختصاصی دارید، باید بین دو گزینه تصمیم بگیرید: افزایش سقف بسته (با ریسک مصرف RAM) یا بهینه‌سازی الگو (با ریسک زمان توسعه). در ۹۰٪ پروژه‌هایی که دیده‌ام، گزینه دوم جواب داده است.

اگر روی پروژه‌ای با این خطا مواجه شده‌اید و روش خاصی برای حلش پیدا کرده‌اید — به‌خصوص اگر با ایمپورت‌های حجیم، مهاجرت‌های بین سرورها، یا ذخیره‌سازی داده‌های ساختاری در دیتابیس سر و کار داشته‌اید — خوشحال می‌شوم تجربه‌تان را بشنوم. بگویید در آن پروژه، مقصر اصلی چه بود: تنظیم هاست، الگوی Export، یا نبود تقسیم‌بندی؟ همین گفت‌وگو برای خواننده بعدی، ارزش یک روز عیب‌یابی را دارد.