جدول wp_options چرا بزرگ می‌شود و چه اثری روی سرعت وردپرس دارد؟

جدول wp_options تنظیمات هسته، قالب و افزونه‌ها را نگه می‌دارد؛ بخشی از داده‌ها نیز با autoload هنگام bootstrap وردپرس خوانده می‌شوند. مشکل فقط تعداد ردیف یا حجم فایل نیست. چند option بزرگ و autoloadشده می‌توانند حافظه و زمان هر request را بالا ببرند، در حالی که هزاران option کوچک و غیرautoload ممکن است اثر فوری کمی داشته باشند.

پاسخ سریع: اندازه کل autoload، بزرگ‌ترین optionها، الگوی نام و مالک آن‌ها را اندازه بگیرید. ابتدا افزونه یا job سازنده را اصلاح کنید و سپس با backup و روی clone، از API یا روش رسمی مالک داده برای حذف استفاده کنید. حذف option ناشناس یا تغییر گروهی autoload روی production می‌تواند سایت را از کار بیندازد.

چه داده‌هایی وارد wp_options می‌شوند؟

• تنظیمات سایت و افزونه‌ها
• داده‌های قالب و widgetها
• transient و cache موقت
• اطلاعات cron و rewrite
• توکن، وضعیت migration یا feature flag
• رکوردهای باقی‌مانده از افزونه حذف‌شده

نام option سرنخ است، نه مدرک مالکیت. پیش از حذف باید کد یا مستندات مؤلفه را بررسی کرد.

Autoload دقیقاً چه اثری دارد؟

وردپرس optionهای autoload را برای کاهش Queryهای جداگانه در ابتدای درخواست بارگذاری می‌کند. این رفتار برای تنظیمات کوچک و پرتکرار مفید است. وقتی payload بسیار بزرگ شود، هزینه انتقال از دیتابیس، deserialize و حافظه PHP روی درخواست‌های متعدد تکرار می‌شود. Object Cache پایدار ممکن است خواندن دیتابیس را کم کند، اما حجم object و هزینه پردازش یا invalidation همچنان مهم است.

اندازه را چگونه بررسی کنیم؟

ابتدا prefix واقعی جدول را پیدا کنید. Queryهای زیر read-only هستند، اما خروجی option_value ممکن است secret یا داده شخصی داشته باشد؛ مقدار کامل را در گزارش عمومی چاپ نکنید:

SELECT autoload,
       COUNT(*) AS option_count,
       ROUND(SUM(OCTET_LENGTH(option_value)) / 1024 / 1024, 2) AS value_mb
FROM wp_options
GROUP BY autoload
ORDER BY value_mb DESC;

SELECT option_name,
       autoload,
       OCTET_LENGTH(option_value) AS value_bytes
FROM wp_options
ORDER BY value_bytes DESC
LIMIT 30;

مقادیر autoload در نسخه‌های مختلف وردپرس ممکن است فقط yes/no نباشند؛ نتیجه را با رفتار نسخه نصب‌شده تفسیر کنید و شرط حذف را از نمونه اینترنتی کپی نکنید.

علت‌های عملی رشد جدول

1. افزونه‌ای که cache یا response بزرگ را به‌عنوان option ذخیره می‌کند.
2. transientهای منقضی یا بدون cleanup مؤثر.
3. ثبت option جدید با نام پویا در هر اجرا.
4. migration ناقص و نگه‌داشتن نسخه‌های قدیمی تنظیمات.
5. افزونه حذف‌شده‌ای که uninstall آن اجرا نشده است.
6. صف، log یا session که اشتباهاً در options نگهداری می‌شود.
7. رشد serialized array واحد به‌جای رکوردهای قابل نگهداری.

چطور مالک option را پیدا کنیم؟

prefix نام، زمان نصب/آپدیت، جست‌وجوی نام option در کد و مستندات uninstall را کنار هم قرار دهید. با WP-CLI می‌توان metadata را خواند، اما نمایش مقدار ممکن است حساس باشد:

wp option get OPTION_NAME --format=json

OPTION_NAME را با نام تأییدشده جایگزین کنید. این فرمان برای ساختار بزرگ خروجی زیادی می‌دهد؛ آن را در ticket عمومی یا shell مشترک ذخیره نکنید.

Transient را کورکورانه حذف نکنید

transient ذاتاً داده موقت است، اما حذف همگانی می‌تواند cache stampede، بار API خارجی یا CPU بالا ایجاد کند. ابتدا expiration، تعداد و مالک را بررسی کنید. اگر transient منقضی دوباره انباشته می‌شود، مشکل cleanup، cron یا افزونه سازنده را رفع کنید؛ پاک‌سازی دوره‌ای فقط علامت را پنهان می‌کند.

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

1. backup قابل restore و clone هم‌نسخه بسازید.
2. حجم autoload و ۳۰ option بزرگ را بدون افشای value ثبت کنید.
3. request کند را profile و ارتباط آن با options را تأیید کنید.
4. مالک و نیاز هر نامزد را مشخص کنید.
5. افزونه سازنده و cleanup رسمی را به‌روزرسانی یا اصلاح کنید.
6. تغییر را ابتدا روی clone اجرا کنید.
7. حافظه PHP، TTFB، Query count و رفتار سایت را قبل و بعد بسنجید.
8. در production تغییر محدود و قابل rollback اعمال کنید.

آیا autoload را خاموش کنیم؟

فقط برای option مشخص و پس از بررسی الگوی مصرف. اگر option در تقریباً هر request لازم باشد، غیرفعال کردن autoload می‌تواند Query جداگانه اضافه کند. اگر تنها در admin یا job خاص خوانده می‌شود، تغییر ممکن است منطقی باشد؛ ولی API رسمی و سازگاری افزونه باید رعایت شود. تصمیم گروهی بر اساس اندازه، رفتارهای پنهان ایجاد می‌کند.

Serialized data و Search/Replace

بسیاری از optionها ساختار serialized یا JSON دارند. ویرایش متنی مستقیم می‌تواند lengthهای serialization را خراب کند یا encoding را تغییر دهد. برای دامنه، مسیر و ساختار داده از ابزار آگاه به serialization مثل WP-CLI و فرمان رسمی مهاجرت استفاده کنید؛ باز هم preview و backup لازم است.

نشانه اینکه علت اصلی جای دیگری است

اگر Query slow log به جدول دیگری اشاره می‌کند، latency شبکه دیتابیس بالا است یا wp-admin فقط هنگام تماس با API خارجی کند می‌شود، کوچک کردن options احتمالاً مسئله اصلی را حل نمی‌کند. Slow Queryها را با شواهد پیدا کنید و برای نقشه کلی‌تر راهنمای بهینه‌سازی دیتابیس وردپرس را ببینید.

اشتباه‌های رایج

• اجرای DELETE با الگوی نام مبهم
• حذف option فعال قالب یا درگاه پرداخت
• اشتراک مقدار option شامل token یا کلید API
• تغییر همه autoloadها به یک مقدار
• نادیده گرفتن prefix واقعی و multisite
• پاک‌سازی cache بدون رفع تولیدکننده داده

معیار موفقیت

کاهش payload autoload باید با افت مصرف حافظه یا زمان bootstrap و بدون Query regression همراه باشد. login، frontend، ذخیره تنظیمات، cron، checkout و callbackهای مهم را smoke test کنید. در چند روز بعد نرخ رشد option و cache miss را دنبال کنید.

چه زمانی کمک تخصصی لازم است؟

اگر option بزرگ مالک روشن ندارد، داده به پرداخت و checkout مربوط است یا تغییر autoload نتیجه متناقض می‌دهد، حذف مستقیم مناسب نیست. سرویس افزایش سرعت وردپرس می‌تواند profile درخواست، object cache و ساختار options را پیش از تغییر production کنار هم بررسی کند.

پرسش‌های متداول

حجم مناسب autoload چقدر است؟

یک عدد جهانی وجود ندارد؛ نسخه، تعداد worker، object cache و latency مهم‌اند. روند رشد و اثر اندازه‌گیری‌شده را معیار قرار دهید.

آیا Redis مشکل wp_options را حل می‌کند؟

ممکن است Query را cache کند، اما payload بزرگ، حافظه و invalidation باقی می‌ماند. علت تولید داده باید اصلاح شود.

آیا حذف افزونه optionهایش را پاک می‌کند؟

همیشه نه. رفتار uninstall هر افزونه متفاوت است و بعضی ابزارها عمداً تنظیمات را برای نصب دوباره نگه می‌دارند.