سایتی که یک سال کار کرده، دیتابیسش فقط از نوشته‌ها و سفارش‌ها تشکیل نشده است. هزاران رونوشت ذخیره‌شده، پیش‌نویس خودکار، transient منقضی و گزینه‌های رها‌شده‌ی افزونه‌های حذف‌شده هم در آن نشسته‌اند. بیشتر این‌ها بی‌ضررند، اما یکی از آن‌ها واقعاً سایت را کند می‌کند: گزینه‌های autoload سنگین.

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

قدم صفر: پشتیبان#

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

Bash
wp db export before-cleanup.sql

بدون WP-CLI، از phpMyAdmin یا ابزار پشتیبان هاست استفاده کنید. روال کامل‌تر در بکاپ خودکار وردپرس آمده است. در دستورهای SQL زیر پیشوند جدول را wp_ فرض کرده‌ایم؛ اگر پیشوند سایتتان فرق دارد، عوضش کنید.

ببینید فضا کجا می‌رود#

اول بدانید کدام جدول‌ها بزرگ‌اند:

Bash
wp db size --tables

معمولاً wp_posts و wp_postmeta و wp_options در صدرند. اگر جدول ناشناسی از یک افزونه‌ی قدیمی عظیم است، اول بفهمید هنوز لازم است یا نه.

autoload: مهم‌ترین نقطه#

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

SQL
SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on')
ORDER BY size_bytes DESC
LIMIT 20;

(مقدارهای مجاز ستون autoload در نسخه‌های جدید وردپرس بیش از yes و no است؛ به همین دلیل چند مقدار را آورده‌ایم.) مجموع حجم را هم ببینید:

SQL
SELECT ROUND(SUM(LENGTH(option_value)) / 1024) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto', 'auto-on');

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

SQL
UPDATE wp_options SET autoload = 'no' WHERE option_name = 'نام_گزینه';

این کار امن‌تر از حذف است و اگر چیزی خراب شد، برمی‌گردد. با گزینه‌هایی که نمی‌شناسید، به‌خصوص نام‌هایی که با _transient شروع نمی‌شوند و مال هسته یا قالب‌اند (مثل siteurl و active_plugins)، کاری نداشته باشید.

transient های منقضی#

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

Bash
wp transient delete --expired

اگر کش شیء پایدار (مثل Redis) دارید، transient ها اصلاً در دیتابیس ذخیره نمی‌شوند و این مشکل کم‌رنگ است.

رونوشت‌ها و پیش‌نویس‌های خودکار#

هر بار «ذخیره» می‌زنید، وردپرس یک رونوشت می‌سازد. در سایتی با چند ساله فعالیت، این‌ها چندین برابر خود نوشته‌ها می‌شوند. دو کار می‌کنیم: سقف بگذاریم و قدیمی‌ها را پاک کنیم. سقف در wp-config.php:

PHP
define( 'WP_POST_REVISIONS', 5 );

و حذف رونوشت‌های موجود (اگر هیچ رونوشتی نبود، دستور خطا می‌دهد که طبیعی است):

Bash
wp post delete $(wp post list --post_type=revision --format=ids) --force
wp post delete $(wp post list --post_status=auto-draft --post_type=any --format=ids) --force

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

جدول‌های رها‌شده و بهینه‌سازی نهایی#

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

Bash
wp db optimize

روی هاست اشتراکی این دستور ممکن است چند دقیقه جدول را قفل کند؛ در ساعت کم‌ترافیک اجرا کنید.

جدول خلاصه#

موردریسککار
transient منقضیکمحذف
رونوشت‌های قدیمیکم تا متوسطمحدودکردن و حذف
auto-draftکمحذف
autoload سنگین افزونه‌ی فعالمتوسطautoload را خاموش کنید
گزینه‌ی افزونه‌ی حذف‌شدهکم، با بررسیحذف
جدول رهاشدهمتوسطبعد از پشتیبان

اگر بعد از این کارها هنوز کند است، سراغ بهینه‌سازی تصاویر وردپرس یا کش بروید؛ دیتابیس تنها عامل نیست.

جلوگیری از انباشت دوباره#

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

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

ابزارهای اندازه‌گیری#

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

خلاصه#

  • قبل از هر حذف، با wp db export یا ابزار هاست پشتیبان بگیرید.
  • گزینه‌های autoload سنگین بیشترین اثر را دارند؛ با کوئری، بزرگ‌ترین‌ها را پیدا کنید.
  • برای افزونه‌ی فعال، autoload را خاموش کنید و رکورد را پاک نکنید.
  • transient های منقضی را بی‌خطر پاک کنید.
  • رونوشت‌ها را با WP_POST_REVISIONS محدود و قدیمی‌ها را حذف کنید.
  • بعد از پاک‌سازی بزرگ، wp db optimize را در ساعت کم‌ترافیک اجرا کنید.