امنیت و نگهداری وردپرس

آموزش بهینه‌سازی دیتابیس وردپرس؛ پاک‌سازی Options، Revisions و جداول ووکامرس

ارسال توسط
0
آموزش بهینه‌سازی و پاک‌سازی دیتابیس وردپرس

🗓 آخرین به‌روزرسانی:

📚 این آموزش بخشی از آموزش جامع وردپرس از صفر تا حرفه‌ای است؛ مسیر کامل یادگیری را آنجا ببینید.
نقشه راه وردپرس ←همه آموزش‌ها

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

هدف بهینه‌سازی حرفه‌ای، کوچک‌کردن کورکورانه دیتابیس نیست؛ هدف این است که داده‌های زائد، منقضی و بدون مالک شناسایی شوند، Queryهای پرتکرار سبک‌تر شوند، جدول‌ها سالم باقی بمانند و رشد آینده کنترل شود. این فرایند باید با اندازه‌گیری، Backup، Staging و تست کامل WooCommerce انجام شود.

در این آموزش، ساختار دیتابیس وردپرس، Options و Autoload، Revisions و Autosave، Trash، Transients، داده‌های Orphan، Comment Meta، User Meta، Sessionهای ووکامرس، Action Scheduler، Analytics، HPOS، Logها، ابزارهای WooCommerce، WP-CLI، Repair و Optimize را مرحله‌به‌مرحله بررسی می‌کنیم.

وضعیت فعلی سایت: dev-source.ir روی WordPress 7.0.2 و WooCommerce 10.9.4 اجرا می‌شود. HPOS و WooCommerce Analytics فعال‌اند و ورود داده‌های Analytics به‌صورت زمان‌بندی‌شده انجام می‌شود. LiteSpeed Cache و چند افزونه سفارشی محصول و Import نیز فعال‌اند. افزونه اختصاصی پاک‌سازی دیتابیس مشاهده نشد و اندازه واقعی جدول‌ها از داخل اتصال فعلی اندازه‌گیری نشده است. در این مقاله هیچ رکورد، Session، Transient یا جدول واقعی سایت حذف و Optimize نمی‌شود.

چرا دیتابیس وردپرس بزرگ می‌شود؟

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

  • Revisionهای زیاد نوشته و محصول
  • Autosaveهای قدیمی
  • Transientهای منقضی
  • Sessionهای رهاشده ووکامرس
  • Action Schedulerهای کامل یا Failed قدیمی
  • Logهای افزونه و درگاه
  • داده افزونه حذف‌شده
  • Optionهای Autoload بزرگ
  • Comment Spam و Trash
  • Metaهای بدون Post، User یا Term
  • داده Analytics و Lookup Tableها
  • Importهای نیمه‌تمام یا صف‌های سفارشی

بزرگ‌بودن دیتابیس همیشه باعث کندی است؟

خیر. یک جدول بزرگ با Index مناسب و Query صحیح می‌تواند سریع باشد، درحالی‌که یک جدول کوچک با Query بد یا Optionهای Autoload سنگین می‌تواند هر درخواست را کند کند.

پیش از پاک‌سازی این شاخص‌ها را اندازه بگیرید:

  • حجم هر جدول
  • تعداد ردیف‌ها
  • Data Length و Index Length
  • Queryهای کند
  • حجم Optionهای Autoload
  • تعداد Revision، Transient و Session
  • رشد روزانه و هفتگی
  • زمان پاسخ صفحات بدون Cache

کاهش چند مگابایت بدون تغییر TTFB یا Query Time، موفقیت عملی محسوب نمی‌شود.

قبل از هر پاک‌سازی چه کار کنیم؟

  1. از فایل و دیتابیس Backup کامل بگیرید.
  2. Restore نسخه را روی Staging آزمایش کنید.
  3. اندازه جدول‌ها را ثبت نمایید.
  4. فهرست افزونه‌های فعال و حذف‌شده را مستند کنید.
  5. عملیات را در ساعت کم‌ترافیک انجام دهید.
  6. Checkout یا Import فعال را متوقف نکنید مگر برنامه مشخص داشته باشید.
  7. پس از هر مرحله سایت را تست کنید.

راهنمای کامل در مقاله آموزش بکاپ و بازیابی وردپرس قرار دارد.

جدول‌های اصلی وردپرس

Prefix ممکن است به‌جای wp_ مقدار دیگری باشد. جدول‌های اصلی معمولاً شامل این موارد هستند:

  • posts: نوشته، برگه، محصول، Revision و Attachment
  • postmeta: اطلاعات تکمیلی محتوا و محصول
  • options: تنظیمات، Transient و داده‌های Autoload
  • users و usermeta: کاربران و تنظیمات حساب
  • terms، term_taxonomy و term_relationships: دسته‌ها و Taxonomyها
  • comments و commentmeta: دیدگاه‌ها و بعضی داده‌های قدیمی سفارش

افزونه‌ها می‌توانند جدول اختصاصی ایجاد کنند. نام جدول به‌تنهایی مجوز حذف آن نیست.

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

در phpMyAdmin معمولاً ستون Size یا Overhead نمایش داده می‌شود. از بخش Database جدول‌ها را بر اساس حجم مرتب کنید و این موارد را ثبت نمایید:

  • نام جدول
  • تعداد ردیف
  • حجم Data
  • حجم Index
  • Overhead
  • افزونه یا ماژول مالک

در سرور دارای WP-CLI می‌توان اطلاعات دیتابیس را از ابزارهای MySQL نیز دریافت کرد، اما ابتدا از دستورهای Read-only استفاده کنید. اجرای Query حذف یا تغییر جدول بدون Backup توصیه نمی‌شود.

Overhead چیست؟

در بعضی Engineها، حذف و Update ردیف‌ها می‌تواند فضای آزاد داخلی ایجاد کند. مقدار Overhead به‌تنهایی نشان نمی‌دهد جدول خراب است. اجرای Optimize ممکن است جدول را بازسازی کند و Lock، I/O یا فضای موقت زیادی مصرف نماید.

برای جدول بزرگ فروشگاه، Optimize را در ساعت کم‌ترافیک و با فضای دیسک کافی انجام دهید.

مرحله دوم: Options و Autoload را تحلیل کنید

جدول Options در بیشتر درخواست‌های وردپرس نقش مهمی دارد. Optionهایی که Autoload هستند می‌توانند در هر Page Load وارد حافظه شوند. اگر افزونه‌ها داده حجیم، Log یا Cache را Autoload کنند، حتی صفحه‌ای که به آن افزونه نیاز ندارد نیز هزینه می‌پردازد.

نشانه‌های Option مشکل‌دار

  • مقدار Serialized بسیار بزرگ
  • Option مربوط به افزونه حذف‌شده
  • Cache یا Log با Autoload فعال
  • آرایه‌ای که دائماً رشد می‌کند
  • چند نسخه تکراری از تنظیمات

حذف Option فقط براساس نام افزونه خطرناک است. افزونه ممکن است غیرفعال باشد اما داده برای فعال‌سازی دوباره لازم باشد.

بررسی Autoload با Site Health

نسخه‌های جدید WordPress در Site Health می‌توانند وضعیت Autoloaded Options را گزارش کنند. مسیر Tools → Site Health را بررسی کنید. اگر هشدار وجود دارد، ابتدا بزرگ‌ترین Optionها و مالک آن‌ها را شناسایی کنید.

راه‌حل همیشه حذف نیست؛ گاهی توسعه‌دهنده باید Autoload را خاموش، داده را به جدول اختصاصی منتقل یا ساختار Option را اصلاح کند.

Transient چیست؟

Transient API برای ذخیره موقت داده دارای زمان انقضا طراحی شده است. Transient می‌تواند در جدول Options یا Object Cache خارجی ذخیره شود.

نکته مهم: زمان Expiration حداکثر زمان تضمین‌شده نگهداری نیست. Transient ممکن است زودتر حذف شود و کد باید توانایی بازسازی آن را داشته باشد.

انواع رایج

  • _transient_...
  • _transient_timeout_...
  • _site_transient_...
  • _site_transient_timeout_...

پاک‌کردن Transientهای منقضی معمولاً کم‌خطرتر از حذف همه Transientهاست. حذف همه می‌تواند بار بازسازی Cache را ناگهان بالا ببرد.

پاک‌سازی Transient با WP-CLI

در محیط دارای WP-CLI می‌توان ابتدا فهرست و سپس موارد منقضی را مدیریت کرد. دستورهای دقیق را براساس نسخه WP-CLI با wp transient --help بررسی کنید.

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

Revision چیست؟

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

پیش از حذف Revision:

  • نوشته‌های در حال ویرایش را مشخص کنید.
  • تاریخچه مهم را نگه دارید.
  • تأثیر Page Builder و WoodMart را بررسی کنید.
  • عملیات را روی Staging تست نمایید.

محدودکردن Revisionهای آینده

در wp-config.php می‌توان تعداد Revisionها را محدود کرد:

define( 'WP_POST_REVISIONS', 10 );

عدد ۱۰ مثال است. برای سایت محتوایی ممکن است تعداد بیشتر و برای داده کم‌تغییر تعداد کمتر مناسب باشد. مقدار false Revision را غیرفعال می‌کند، اما امکان بازگشت محتوا را از بین می‌برد و معمولاً توصیه نمی‌شود.

این تنظیم Revisionهای قدیمی موجود را حذف نمی‌کند؛ فقط رفتار آینده را کنترل می‌کند.

Autosave را با Revision اشتباه نگیرید

Autosave برای جلوگیری از ازدست‌رفتن کار هنگام ویرایش است. فاصله پیش‌فرض را می‌توان با Constant تنظیم کرد:

define( 'AUTOSAVE_INTERVAL', 120 );

مقدار برحسب ثانیه است. افزایش زیاد Interval ریسک ازدست‌رفتن تغییر را بالا می‌برد. Autosave را فقط برای کوچک‌کردن دیتابیس غیرفعال نکنید.

Trash و داده‌های حذف‌شده

نوشته، برگه، محصول و دیدگاه منتقل‌شده به Trash فوراً حذف دائمی نمی‌شوند. این رفتار برای بازیابی اشتباه مفید است.

مدت نگهداری Trash را می‌توان در wp-config.php تنظیم کرد:

define( 'EMPTY_TRASH_DAYS', 14 );

عدد ۱۴ نمونه است. صفرکردن مقدار باعث حذف فوری و حذف فرصت بازیابی می‌شود. برای فروشگاه، محصول و سفارش را بدون سیاست نگهداری دائمی حذف نکنید.

دیدگاه Spam و Pending

Comment Spam، Trash و Metaهای وابسته می‌توانند رشد کنند. قبل از حذف گروهی:

  • دیدگاه واقعی را بررسی کنید.
  • Order Noteها را با Comment اشتباه نگیرید.
  • افزونه‌ای که از Comments استفاده می‌کند شناسایی شود.
  • Backup دیتابیس تهیه شود.

در WooCommerce جدید و HPOS، ساختار سفارش نسبت به نسخه‌های قدیمی متفاوت است؛ Queryهای قدیمی اینترنتی را بدون شناخت اجرا نکنید.

داده Orphan چیست؟

داده Orphan ردیفی است که Parent آن دیگر وجود ندارد؛ برای مثال Post Meta بدون Post معتبر. این وضعیت می‌تواند بعد از حذف ناقص افزونه، Import شکست‌خورده یا Query مستقیم ایجاد شود.

نمونه‌ها

  • Post Meta بدون Post
  • Comment Meta بدون Comment
  • Term Relationship بدون Object
  • User Meta بدون User
  • Permission دانلود بدون سفارش یا محصول معتبر

شناسایی Orphan به معنی حذف خودکار نیست. بعضی افزونه‌ها شناسه خارجی یا ساختار خاص دارند که با Query عمومی اشتباه تشخیص داده می‌شود.

پاک‌سازی داده افزونه حذف‌شده

حذف افزونه ممکن است جدول و Optionهای آن را نگه دارد تا در نصب دوباره تنظیمات حفظ شوند. روند امن:

  1. نام دقیق افزونه و Prefix داده را پیدا کنید.
  2. مستندات Uninstall را بررسی نمایید.
  3. تأیید کنید افزونه دیگری از همان جدول استفاده نمی‌کند.
  4. Export جدول یا Option بگیرید.
  5. روی Staging حذف و سایت را تست کنید.
  6. سپس در Production اجرا نمایید.

جست‌وجوی نام برند در جدول‌ها کافی نیست؛ بعضی افزونه‌ها نام عمومی یا Prefix مشترک دارند.

Object Cache با Transient و Page Cache چه تفاوتی دارد؟

  • Page Cache: HTML کامل صفحه را ذخیره می‌کند.
  • Object Cache: نتیجه Query و Objectهای داخلی را نگه می‌دارد.
  • Transient: API موقت داده در WordPress است.

LiteSpeed Cache می‌تواند چند نوع Cache را مدیریت کند، اما تنظیمات دقیق به سرور و Object Cache موجود وابسته است. پاک‌کردن دیتابیس بدون کنترل Cache می‌تواند باعث نمایش داده قدیمی شود؛ پس از عملیات Purge هدفمند انجام دهید.

Sessionهای WooCommerce

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

قبل از پاک‌سازی Session

  • زمان کم‌ترافیک انتخاب کنید.
  • Checkoutهای فعال را در نظر بگیرید.
  • نوع Storage را بررسی کنید.
  • فقط Expired Sessionها را هدف بگیرید.
  • Cart و Checkout را بعد از عملیات تست کنید.

در تنظیمات فعلی سایت، قابلیت آزمایشی حذف Sessionهای خالی فعال نیست؛ بنابراین هر تغییر در این بخش باید جداگانه آزمایش شود.

ابزارهای WooCommerce Status

در WooCommerce → Status → Tools بسته به نسخه و افزونه‌ها ابزارهایی برای پاک‌کردن Transient، Session مشتری، Cache Template، Analytics Cache و بازسازی جدول‌های Lookup وجود دارد.

هر ابزار شرح و اثر متفاوت دارد. قبل از Run:

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

HPOS و جدول سفارش‌ها

High-Performance Order Storage سفارش‌ها را در جدول‌های اختصاصی ووکامرس ذخیره می‌کند. در سایت فعلی HPOS فعال است. بنابراین دستورهای قدیمی که سفارش را فقط در posts و postmeta جست‌وجو یا حذف می‌کنند، ممکن است ناقص یا خطرناک باشند.

برای سفارش از CRUD و API رسمی WooCommerce استفاده کنید. حذف دستی ردیف‌های HPOS می‌تواند ارتباط آدرس، Operational Data، Order Item و Analytics را خراب کند.

آیا جدول‌های قدیمی سفارش را حذف کنیم؟

پس از مهاجرت HPOS ممکن است Compatibility Mode یا Sync وجود داشته باشد. حذف جدول یا ردیف قدیمی فقط زمانی مجاز است که:

  • HPOS کامل و همگام باشد.
  • افزونه‌های قدیمی به ساختار Legacy وابسته نباشند.
  • ابزار رسمی WooCommerce وضعیت را تأیید کند.
  • Backup و Restore تست شده باشد.
  • مستندات نسخه فعلی بررسی شود.

هیچ جدول سفارش را صرفاً به‌دلیل نام قدیمی حذف نکنید.

WooCommerce Analytics و Lookup Tables

Analytics داده‌های سفارش و محصول را برای گزارش‌گیری پردازش می‌کند. سایت فعلی Analytics و Scheduled Import را فعال دارد. جدول‌های Lookup و Stats ممکن است قابل بازسازی باشند، اما بازسازی روی فروشگاه بزرگ زمان و CPU مصرف می‌کند.

اگر گزارش با سفارش اختلاف دارد:

  1. بازه و Date Type را بررسی کنید.
  2. Scheduled Update را کنترل نمایید.
  3. Analytics Cache را پاک کنید.
  4. در صورت نیاز Historical Data را Import کنید.
  5. فقط در آخر جدول‌های مرتبط را با ابزار رسمی بازسازی کنید.

جزئیات در مقاله آموزش WooCommerce Analytics توضیح داده شده است.

Action Scheduler

WooCommerce و افزونه‌های دیگر Jobهای پس‌زمینه را در Action Scheduler ثبت می‌کنند. جدول‌های این سیستم می‌توانند با Actionهای Complete، Failed و Logها رشد کنند.

قبل از پاک‌سازی

  • صف Pending و In-progress را بررسی کنید.
  • Hook و Group را شناسایی نمایید.
  • Failedها را برای یافتن علت نگه دارید.
  • Jobهای مالی، Import و ایمیل را از داده زائد جدا کنید.
  • از Cleanup داخلی و Retention سازگار استفاده نمایید.

حذف مستقیم Action Pending می‌تواند Import یا ارسال سفارش را ناقص کند.

Logهای WooCommerce و افزونه‌ها

Log باید دوره نگهداری مشخص داشته باشد. Logger ووکامرس می‌تواند فایل یا دیتابیس را استفاده کند. ذخیره Debug در دیتابیس و نگهداری نامحدود آن رشد قابل‌توجهی ایجاد می‌کند.

  • Debug را فقط هنگام عیب‌یابی فعال کنید.
  • Retention را متناسب با نیاز حقوقی تعیین نمایید.
  • Log قدیمی را Rotate و حذف کنید.
  • Secret و اطلاعات حساس را داخل Log ثبت نکنید.

راهنمای فنی Logها در مقاله مانیتورینگ وردپرس و بررسی لاگ‌ها قرار دارد.

Rank Math و جدول‌های سئو

Rank Math ماژول‌های Analytics، 404 Monitor، Redirection و Instant Indexing دارد. این ماژول‌ها می‌توانند Log یا Cache تولید کنند. قبل از پاک‌سازی:

  • Retention بخش 404 را بررسی کنید.
  • Redirectهای فعال را حذف نکنید.
  • Cache Sitemap را با ابزار خود افزونه بازسازی کنید.
  • Log ارسال IndexNow را از داده اصلی سئو جدا بدانید.

حذف جدول یا Option سئو می‌تواند Meta Title، Schema، Redirection و Sitemap را تحت تأثیر قرار دهد.

Importهای سفارشی و جدول صف

سایت فعلی افزونه‌های سفارشی Import و پردازش محصول دارد. این ابزارها ممکن است Queue، Progress، Error و Temporary Mapping ذخیره کنند.

برای هر افزونه باید مشخص باشد:

  • داده اصلی کدام است؟
  • داده موقت چه زمانی منقضی می‌شود؟
  • Job نیمه‌تمام چگونه Resume می‌شود؟
  • Log تا چه زمانی نگهداری می‌شود؟
  • Uninstall چه جدول‌هایی را حذف می‌کند؟

پاک‌سازی عمومی نمی‌تواند ساختار افزونه سفارشی را با اطمینان تشخیص دهد.

Optimize Table با WP-CLI

WP-CLI دستور زیر را برای Optimize دیتابیس ارائه می‌کند:

wp db optimize

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

  • Backup بگیرید.
  • فضای آزاد دیسک را بررسی کنید.
  • فروشگاه پرترافیک را در Maintenance Window قرار دهید.
  • Engine و اندازه جدول را بشناسید.
  • زمان اجرا و Lock احتمالی را در نظر بگیرید.

اجرای روزانه Optimize بدون دلیل ضروری نیست و می‌تواند I/O اضافی ایجاد کند.

Repair دیتابیس با WP-CLI

برای بررسی و Repair در محیط دارای دسترسی مناسب:

wp db check
wp db repair

Repair برای خرابی جدول است، نه راهکار عمومی کندی. خطای Connection، Query بد یا Table Lock با Repair خودکار حل نمی‌شود.

ابزار WP_ALLOW_REPAIR

WordPress یک صفحه Repair داخلی دارد. برای فعال‌سازی موقت:

define( 'WP_ALLOW_REPAIR', true );

سپس صفحه Repair قابل دسترسی می‌شود. این صفحه بدون Login نیز قابل اجراست، زیرا ممکن است دیتابیس اجازه ورود ندهد. بنابراین پس از پایان، Constant را فوراً حذف یا false کنید.

از این ابزار فقط برای Repair یا Optimize جدول‌ها استفاده کنید، نه پاک‌سازی Option و Meta.

phpMyAdmin؛ Repair و Optimize

در phpMyAdmin می‌توان جدول‌ها را انتخاب و Check، Repair یا Optimize کرد. روی جدول‌های بزرگ:

  • زمان اجرا را پیش‌بینی کنید.
  • از اجرای هم‌زمان Backup و Import خودداری کنید.
  • Progress و Error Log را بررسی نمایید.
  • مرورگر را معیار موفقیت ندانید؛ ممکن است Request Timeout شود ولی عملیات سرور ادامه یابد.

آیا باید Index جدید بسازیم؟

Index می‌تواند Query خواندن را سریع‌تر کند، اما فضای دیسک و هزینه Insert و Update را افزایش می‌دهد. Index باید براساس Slow Query واقعی و Execution Plan طراحی شود.

افزودن Index تصادفی روی meta_value یا ستون‌های طولانی معمولاً راهکار عمومی نیست. برای افزونه سفارشی، Schema و Query باید توسط توسعه‌دهنده بررسی شود.

پایگاه داده و Object Cache

Persistent Object Cache مانند Redis می‌تواند تعداد Queryهای تکراری را کاهش دهد، اما دیتابیس زائد را حذف نمی‌کند. Cache فقط علائم بعضی Queryها را پنهان می‌کند و پس از Purge مشکل اصلی دوباره ظاهر می‌شود.

قبل از فعال‌سازی:

  • سازگاری هاست و LiteSpeed را بررسی کنید.
  • Prefix Cache برای هر سایت جدا باشد.
  • Cart و Session ووکامرس تست شوند.
  • Hit Ratio و Memory Eviction مانیتور شود.

بهینه‌سازی دیتابیس با افزونه

افزونه پاک‌سازی می‌تواند رابط ساده برای Revision، Transient، Spam و Optimize ارائه دهد؛ اما گزینه «Select All» خطرناک است.

معیار انتخاب افزونه

  • سازگاری با WordPress و WooCommerce فعلی
  • پشتیبانی HPOS
  • نمایش Preview و تعداد ردیف
  • امکان Backup یا تأیید چندمرحله‌ای
  • عدم حذف خودکار جدول ناشناس
  • Log عملیات
  • پشتیبانی از Scheduled Cleanup کنترل‌شده

هم‌زمان چند افزونه پاک‌سازی نصب نکنید. قابلیت Database Optimization خود LiteSpeed نیز در صورت استفاده باید جداگانه و مرحله‌ای بررسی شود.

ترتیب پیشنهادی پاک‌سازی

  1. اندازه‌گیری و Backup
  2. Trash و Spam واضح
  3. Transientهای منقضی
  4. Revisionهای قدیمی با سیاست مشخص
  5. Sessionهای منقضی
  6. Logهای قدیمی
  7. Action Scheduler Complete قدیمی طبق Retention
  8. Option و جدول افزونه حذف‌شده پس از تأیید مالکیت
  9. داده Orphan پس از بررسی
  10. Optimize فقط در صورت نیاز

بعد از هر مرحله اندازه و عملکرد را دوباره ثبت کنید. همه مراحل را یک‌جا اجرا نکنید؛ در غیر این صورت علت خطا مشخص نمی‌شود.

تست بعد از پاک‌سازی

WordPress

  • ورود مدیر
  • ویرایش و ذخیره نوشته
  • Revision و Autosave
  • آپلود رسانه
  • جست‌وجو و دسته‌ها
  • Sitemap و Redirect

WooCommerce

  • محصول و Variation
  • افزودن به سبد
  • خرید مهمان و حساب‌دار
  • درگاه و Callback آزمایشی
  • سفارش، ایمیل و Download
  • Refund و موجودی
  • Analytics و Scheduled Actions

فنی

  • PHP Error Log
  • Slow Query
  • CPU و Disk I/O
  • Actionهای Failed
  • Object Cache
  • Backup بعدی

خطا: سایت بعد از حذف Option از کار افتاد

Option هنوز متعلق به افزونه یا قالب فعال بوده است. دیتابیس را از Backup برگردانید یا Option را از نسخه Exportشده Restore کنید. ساخت مقدار خالی دستی ممکن است ساختار Serialized صحیح را نداشته باشد.

خطا: Cart مشتریان خالی شد

Sessionهای فعال یا Object Cache پاک شده‌اند. بررسی کنید ابزار به‌جای Expired Session همه Sessionها را حذف نکرده باشد.

خطا: Analytics خالی یا ناقص شد

Lookup یا Stats Table پاک شده است. از ابزار رسمی Import Historical Data یا Regenerate استفاده کنید و Scheduled Actions را مانیتور نمایید.

خطا: Action Scheduler دوباره سریع رشد می‌کند

پاک‌سازی علامت را حذف کرده، اما افزونه‌ای Job بیش‌ازحد تولید می‌کند یا Jobها Fail می‌شوند. Hook، Group و Log را تحلیل و علت را در کد یا تنظیمات اصلاح کنید.

خطا: Optimize فضای دیسک را پر کرد

بازسازی جدول ممکن است فضای موقت هم‌اندازه یا بزرگ‌تر از جدول نیاز داشته باشد. عملیات را متوقف‌کردن کورکورانه خطرناک است؛ با مدیر سرور هماهنگ و فضای کافی تأمین کنید.

خطا: wp_options دوباره بزرگ شد

یک افزونه داده را مداوم Autoload یا Cache می‌کند. بزرگ‌ترین Optionها را در دو زمان مقایسه و مالک تولیدکننده را شناسایی کنید. حذف دوره‌ای بدون اصلاح افزونه راهکار پایدار نیست.

خطا: بعد از پاک‌سازی صفحه قدیمی نمایش داده می‌شود

Page Cache، Object Cache، CDN یا OPcache هنوز داده قبلی را نگه داشته است. Purge هدفمند انجام دهید و از پاک‌کردن هم‌زمان همه Cacheها در ساعت شلوغ خودداری کنید.

برنامه نگهداری پیشنهادی

هفتگی

  • بررسی حجم Log و Action Failed
  • پاک‌سازی Spam و Trash تأییدشده
  • کنترل Backup

ماهانه

  • اندازه جدول‌های بزرگ
  • Autoloaded Options
  • Expired Transients و Sessionها
  • Action Scheduler و Analytics Queue
  • Restore آزمایشی

فصلی

  • داده افزونه‌های حذف‌شده
  • Slow Query و Index
  • Retention Log
  • سیاست Revision
  • افزونه‌های سفارشی و جدول‌های آن‌ها

برنامه پیشنهادی برای dev-source.ir

  1. از دیتابیس Full Export و Restore آزمایشی گرفته شود.
  2. حجم جدول‌ها و Autoload Options اندازه‌گیری شود.
  3. HPOS و همگام‌بودن سفارش‌ها تأیید گردد.
  4. Action Scheduler بر اساس Hook و Group تحلیل شود.
  5. WooCommerce Analytics و Historical Import بدون حذف جدول بررسی شوند.
  6. Sessionهای منقضی در ساعت کم‌ترافیک پاک شوند.
  7. Revisionها با سقف منطقی برای مقالات طولانی محدود شوند.
  8. Rank Math 404 و Indexing Log دارای Retention مشخص باشند.
  9. افزونه‌های سفارشی Import و PDF سیاست Cleanup داخلی داشته باشند.
  10. پس از هر مرحله Cart، Checkout، درگاه و دانلود تست شوند.

چک‌لیست نهایی بهینه‌سازی دیتابیس

  • Backup و Restore تست شده است.
  • اندازه جدول‌ها قبل از عملیات ثبت شده است.
  • Optionهای بزرگ و Autoload شناسایی شده‌اند.
  • Transient منقضی از Cache فعال جدا شده است.
  • Revision با سیاست مشخص مدیریت می‌شود.
  • Trash و Spam بررسی شده‌اند.
  • داده Orphan قبل از حذف تأیید شده است.
  • Session فعال مشتری حذف نمی‌شود.
  • HPOS در Queryها لحاظ شده است.
  • Analytics و Lookup فقط با ابزار رسمی بازسازی می‌شوند.
  • Action Scheduler Pending حذف نشده است.
  • Logها Retention و Rotation دارند.
  • Optimize در Maintenance Window انجام می‌شود.
  • دستور SQL ناشناس اجرا نشده است.
  • پس از عملیات WooCommerce کامل تست شده است.

📌 همچنین بخوانید: ارتقای نسخه PHP وردپرس، نگهداری دوره‌ای وردپرس و انتقال وردپرس به هاست جدید

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

هر چند وقت دیتابیس وردپرس را Optimize کنیم؟

برنامه ثابت برای همه سایت‌ها وجود ندارد. ابتدا Overhead، رشد و Query Time را اندازه بگیرید. Optimize مکرر بدون نیاز می‌تواند بار اضافی ایجاد کند.

آیا حذف Revision امن است؟

Revision قدیمی قابل حذف است، اما تاریخچه ویرایش را از بین می‌برد. ابتدا Backup و سیاست نگهداری مشخص داشته باشید.

آیا همه Transientها را پاک کنیم؟

در حالت عادی پاک‌سازی موارد منقضی امن‌تر است. حذف همه می‌تواند Cacheها را هم‌زمان بازسازی و بار سرور را زیاد کند.

آیا HPOS دیتابیس ووکامرس را خودکار کوچک می‌کند؟

HPOS ساختار سفارش را بهینه‌تر می‌کند، اما Session، Log، Analytics و Action Scheduler همچنان نیازمند نگهداری هستند.

آیا پاک‌سازی دیتابیس سرعت سایت را تضمین می‌کند؟

خیر. کندی ممکن است از PHP، Query افزونه، هاست، تصاویر، JavaScript یا Cache باشد. نتیجه را با اندازه‌گیری تأیید کنید.

بهترین افزونه پاک‌سازی چیست؟

انتخاب به HPOS، حجم دیتابیس و نیاز Preview بستگی دارد. مهم‌تر از نام افزونه، Backup، نمایش دقیق داده و اجرای مرحله‌ای است.

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

فقط پس از تأیید مالکیت جدول، نبود وابستگی، گرفتن Export و تست روی Staging.

جمع‌بندی

بهینه‌سازی دیتابیس وردپرس باید با اندازه‌گیری شروع شود، نه با حذف. Options و Autoload روی هر درخواست اثر دارند؛ Revision و Transient باید با سیاست نگهداری مدیریت شوند؛ و داده‌های WooCommerce مانند Session، HPOS، Analytics و Action Scheduler باید فقط با ابزارهای سازگار نسخه فعلی پاک‌سازی شوند.

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

در سایت فعلی، اولویت با اندازه‌گیری جدول‌ها، تحلیل Autoload، بررسی Queueهای سفارشی، Retention لاگ‌ها و پاک‌سازی کنترل‌شده داده‌های منقضی است؛ نه اجرای Queryهای عمومی اینترنتی.

منابع رسمی

آموزش‌های تازه، کد آماده و رفع خطاهر هفته در کانال Dev Source؛ رایگان.
✈️ کانال تلگرام🟣 کانال روبیکا
جدیدتر
آموزش ساخت Staging وردپرس؛ کلون سایت، تست تغییرات و انتقال امن به سایت اصلی
بازگشت به لیست
قدیمی تر آموزش مانیتورینگ وردپرس و بررسی لاگ‌ها؛ Uptime، خطاهای PHP و گزارش‌های ووکامرس

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *