بزرگ شدن دیتابیس به‌تنهایی ثابت نمی‌کند که وردپرس کند است. یک فروشگاه با سفارش‌های واقعی ممکن است دیتابیس چند گیگابایتی و عملکرد سالم داشته باشد، در حالی که سایتی کوچک به‌دلیل autoload نامناسب، Query بدون index یا صف شکست‌خورده کند شود. هدف بهینه‌سازی، کم کردن عدد حجم به هر قیمت نیست؛ باید هزینه خواندن و نوشتن، داده بی‌مالک و امکان بازیابی را اصلاح کرد.
پاسخ سریع: ابتدا backup قابل بازیابی بگیرید، اندازه جدول و index را جدا اندازه بگیرید، رشد را در طول زمان ببینید و جدول بزرگ را به افزونه یا قابلیت مالک نسبت دهید. سپس retention و ابزار پاک‌سازی رسمی همان مؤلفه را بررسی کنید. عملیات حذف یا تغییر index را ابتدا روی clone هم‌نسخه اجرا و زمان، lock و نتیجه عملکردی را بسنجید.
چه زمانی بزرگی دیتابیس واقعاً مسئله است؟
- backup یا restore از RTO قابل‌قبول عبور می‌کند.
- Queryهای پرتکرار rows زیادی می‌خوانند یا روی disk spill می‌شوند.
- جدول بدون چرخه نگهداری پیوسته رشد می‌کند.
- wp-admin، جست‌وجو، checkout یا job پس‌زمینه منتظر دیتابیس است.
- فضای آزاد برای temporary table، log یا maintenance کافی نیست.
- داده متعلق به افزونه حذف‌شده یا job شکست‌خورده است.
اندازه را همراه latency، نرخ رشد و workload تفسیر کنید. اجرای یک Query سریع روی جدول بزرگ ممکن است سالم‌تر از scan کامل جدول کوچک باشد.
پیش از هر پاک‌سازی: مسیر بازگشت بسازید
یک dump تازه کافی نیست مگر اینکه کامل بودن آن و امکان restore تأیید شود. برای سایت فروشگاهی، فاصله بین backup و زمان تغییر می‌تواند شامل سفارش و پرداخت جدید باشد؛ بنابراین maintenance window یا برنامه حفظ delta لازم است. مدت restore را روی محیط جدا اندازه بگیرید و backup قبلی را با خروجی تازه جایگزین نکنید تا یک نقطه بازیابی مستقل باقی بماند.
نقشه دیتابیس را تهیه کنید
در MySQL/MariaDB می‌توان اندازه تقریبی data و index را از information_schema.tables خواند. نام دیتابیس را از پیکربندی معتبر بگیرید و رمز را در command history یا گزارش عمومی نگذارید:
SELECT table_name,
ROUND(data_length / 1024 / 1024, 1) AS data_mb,
ROUND(index_length / 1024 / 1024, 1) AS index_mb,
table_rows
FROM information_schema.tables
WHERE table_schema = DATABASE()
ORDER BY data_length + index_length DESC;table_rows برای برخی engineها تخمینی است. این گزارش فقط نامزد بررسی می‌سازد و مجوز حذف جدول نیست. prefix نیز الزاماً wp_ نیست.
جدول بزرگ متعلق به چه چیزی است؟
| الگو | پرسش اصلی | اقدام کم‌ریسک |
|---|---|---|
| posts/postmeta | revision، محصول یا meta متعلق به کدام افزونه است؟ | گزارش نوع رکورد و مالکیت داده |
| options | autoload و transient چه سهمی دارند؟ | تحلیل نام option و اندازه، نه حذف گروهی |
| سشن/صف/لاگ | retention و consumer سالم است؟ | ابزار cleanup رسمی و رفع علت backlog |
| جداول افزونه قدیمی | آیا افزونه واقعاً حذف و داده قابل نگهداری نیست؟ | مستندات uninstall و backup مستقل |
| WooCommerce | داده سفارش، lookup یا Action Scheduler است؟ | ابزارهای خود ووکامرس و آزمون گزارش‌ها |
یک فرایند عملی و قابل بازگشت
- حجم، latency و نرخ رشد را baseline کنید.
- backup فایل و دیتابیس را بگیرید و restore را آزمایش کنید.
- جدول‌های بزرگ و indexهایشان را فهرست کنید.
- مالک هر جدول یا prefix و سیاست retention را مشخص کنید.
- نمونه داده و قدیمی‌ترین/جدیدترین timestamp را بررسی کنید.
- پاک‌سازی رسمی را روی clone اجرا و اختلاف تعداد رکورد را ثبت کنید.
- عملیات را batch کنید تا transaction و lock کنترل شود.
- پس از اجرا، مسیرهای تجاری و Queryهای هدف را دوباره بسنجید.
Revision، transient و orphan؛ برچسب کافی نیست
revisionها ممکن است برای بازگشت محتوای درحال ویرایش لازم باشند. transient منقضی‌شده معمولاً نامزد پاک‌سازی است، اما transient فعال یا timeout جداگانه دارد. «orphan» نیز باید بر اساس رابطه واقعی و رفتار افزونه تعریف شود؛ یک meta بدون parent شاید اثر migration ناقص باشد. ابزار پاک‌سازی نباید صرفاً با تطبیق نام جدول تصمیم بگیرد.
OPTIMIZE TABLE چه زمانی مفید است؟
این عملیات درمان عمومی کندی نیست. رفتار reclaim و rebuild به engine و نسخه وابسته است و ممکن است I/O، فضای موقت و lock قابل‌توجه ایجاد کند. ابتدا fragmentation، فضای موردنیاز، مدت اجرا و امکان online operation را برای نسخه دقیق بررسی کنید. اجرای آن روی همه جدول‌ها در ساعت پرترافیک می‌تواند از خود مشکل بدتر باشد.
Index اضافه کنیم یا نه؟
فقط پس از مشاهده Query واقعی و execution plan تصمیم بگیرید. index مناسب می‌تواند rows examined را کاهش دهد، ولی index اضافی فضای دیسک و هزینه insert/update را بالا می‌برد. تغییر schema افزونه ممکن است در update بعدی تعارض بسازد. روش پیدا کردن Slow Queryهای وردپرس نقطه شروع بهتری از index حدسی است.
wp_options را جدا بررسی کنید
در این جدول اندازه autoload، تعداد optionها و مالک هر رکورد مهم‌تر از حجم کلی است. حذف option ناشناخته می‌تواند تنظیمات، license، route یا cache حیاتی را خراب کند. برای تحلیل مرحله‌ای، راهنمای رشد جدول wp_options را ببینید.
بعد از پاک‌سازی چه چیزهایی را تست کنیم؟
- ورود و ذخیره نوشته یا محصول
- جست‌وجو و فیلترهای پرترافیک
- سبد، checkout، پرداخت و callback
- cron، queue، ایمیل و sync خارجی
- گزارش‌ها و صفحه سفارش‌های قدیمی
- زمان backup و restore آزمایشی
کاهش حجم بدون بهبود Query هدف یا عملیات نگهداری، نتیجه عملکردی محسوب نمی‌شود.
اشتباه‌های رایج
- حذف همه transientها یا جدول‌ها روی production بدون backup
- استفاده از prefix ثابت
wp_در دستورها - خالی کردن صف برای پنهان کردن consumer خراب
- restore کردن backup قدیمی فروشگاه و از دست دادن سفارش تازه
- ساخت index از روی حدس یا توصیه مربوط به نسخه دیگر
- اجرای OPTIMIZE همگانی در زمان اوج
چگونه از رشد دوباره جلوگیری کنیم؟
برای log، session، revision و queue سیاست retention مشخص کنید؛ failure و قدیمی‌ترین job را مانیتور کنید؛ نرخ رشد جدول را هفتگی ثبت کنید و پیش از نصب افزونه، مدل داده و uninstall آن را بررسی کنید. backup باید خارج از همان failure domain و restore آن دوره‌ای آزموده شود.
چه زمانی بررسی تخصصی لازم است؟
اگر جدول تراکنشی بسیار بزرگ است، فضای آزاد برای rebuild ندارید یا Query کند با checkout و سفارش درگیر است، آزمون مستقیم خطر دارد. در سرویس افزایش سرعت وردپرس می‌توان اندازه، slow log و execution plan را روی clone تحلیل کرد و تغییر قابل rollback ساخت.
پرسش‌های متداول
آیا افزونه پاک‌سازی دیتابیس کافی است؟
تنها وقتی نوع داده، مالک و retention را درست تشخیص دهد. قبل از اجرا preview، backup و رفتار نسخه دقیق را بررسی کنید.
آیا حذف revisionها سایت را سریع می‌کند؟
الزاماً نه. اثر به حجم و Queryها بستگی دارد و تاریخچه ویرایش نیز از دست می‌رود.
آیا دیتابیس چند گیگابایتی حتماً مشکل دارد؟
خیر. latency، plan، نرخ رشد و زمان بازیابی معیارهای کاربردی‌تری از حجم تنها هستند.