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

مدیریت داده‌های موقت در وردپرس، همان لایه‌ای است که اکثر توسعه‌دهندگان تا روزی که دیتابیس سایت مشتری از کنترل خارج شود، به آن فکر نمی‌کنند. من در بازبینی سایت‌های سه، چهار ساله بارها به دیتابیسی برخورده‌ام که حجمش با محتوای واقعی سایت هم‌خوانی ندارد — گاهی سه‌چهار برابر آن چیزی است که باید باشد. ریشه این رشد پنهان، نه در محتوا، بلکه در ردیف‌های موقتی است که هیچ‌کس مسئول پاک‌سازی‌شان نبوده: Revisionهای انبار‌شده، Transientهای منقضی، Cronهای جامانده از افزونه‌های حذف‌شده و optionهایی که با هر بار لود شدن سایت، از دیسک خوانده می‌شوند.

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

داده موقت چیست و مرز آن با محتوای دائمی کجاست؟

داده موقت در وردپرس، هر ردیفی است که وجودش برای عملکرد حال حاضر سایت لازم است ولی اگر فردا حذف شود، کاربر نهایی چیزی را از دست نمی‌دهد. برعکس آن، داده دائمی است: نوشته، برگه، سفارش ووکامرس، کاربر و تنظیمات اصلی. این مرز در تئوری شفاف به نظر می‌رسد ولی در پروژه‌های واقعی، پر از مناطق خاکستری است. مثلاً یک Transient که نرخ ارز را کش کرده، داده موقت است؛ ولی اگر همان نرخ ارز در فاکتور سفارش مشتری ذخیره شده باشد، آن نسخه، داده دائمی است. تشخیص این مرز، اولین قدم مدیریت درست است.

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

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

چهار دسته داده موقت در وردپرس

در پروژه‌های واقعی، من داده موقت وردپرس را به چهار دسته تقسیم می‌کنم. هر دسته رفتار متفاوتی دارد و مدیریتشان هم متفاوت است.

دسته اول: کش و Transient

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

دسته دوم: رویدادهای زمان‌بندی‌شده

Cronهای وردپرس در این دسته قرار می‌گیرند. یک Cron با نام مشخص در جدول wp_options به‌عنوان یک ردیف ثبت می‌شود و هر بار که زمانش می‌رسد، اجرا می‌شود. مشکل زمانی رخ می‌دهد که افزونه‌ای حذف می‌شود ولی Cron آن باقی می‌ماند و دیگر هیچ تابعی برای اجرا وجود ندارد. این وضعیت که در رفع مشکلات کرون در وردپرس مفصل توضیح داده‌ام، یکی از منابع اصلی داده‌های یتیم است. در پروژه‌ای با بیست افزونه، بعد از حذف ده افزونه، نزدیک بیست Cron یتیم پیدا کردم که در هر بازدید سایت چک می‌شدند بدون اینکه هیچ کاری انجام دهند.

دسته سوم: داده‌های ساختاری محتوا

Revisionها، Auto-draftها، Trash شده‌ها و Commentهای اسپم در این دسته قرار می‌گیرند. این داده‌ها در فرآیند تولید محتوا ایجاد می‌شوند ولی بعد از انتشار، نیاز به پاک‌سازی دوره‌ای دارند. یک سایت با هزار نوشته و تنظیم پیش‌فرض Revision، می‌تواند میلیون‌ها ردیف در جدول wp_posts داشته باشد — بیشتر از خود محتوا. برای درک عمیق‌تر این دسته و اثرش روی سرعت، تاثیر دیتابیس بر سرعت سایت چقدر است تحلیل دقیقی دارد.

دسته چهارم: داده‌های مرتبط با کاربر و نشست

Sessions، Tokenهای موقت، داده‌های ورود موقت و مشابه در این دسته‌اند. این نوع داده، حساس‌ترین دسته از نظر امنیتی است چون در صورت نشت، پیامد مستقیم روی امنیت کاربر دارد. مدیریت این دسته، باید هم‌راستا با امن‌سازی نشست‌های کاربری انجام شود و همان اصول پاک‌سازی داده که در پاک‌سازی داده‌ها در کدنویسی وردپرس توضیح داده شده، در اینجا هم بی‌استثناست.

چرخه حیات داده موقت: از تولد تا پاک‌سازی

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

الگوی اول: انقضای زمان‌محور

داده با یک زمان مشخص ایجاد می‌شود و در همان زمان مشخص از دسترس خارج می‌شود. این الگو برای Transient و Cache استفاده می‌شود. نکته‌ای که در پیاده‌سازی زیاد نادیده گرفته می‌شود، تفاوت بین «از دسترس خارج شدن» و «حذف شدن از دیتابیس» است که در بخش بهینه‌سازی دیتابیس وردپرس چیست توضیح داده‌ام.

الگوی دوم: انقضای رویدادمحور

داده موقت با یک رویداد خاص بی‌اعتبار می‌شود. مثلاً Cache صفحه یک نوشته، با انتشار همان نوشته بی‌اعتبار می‌شود. این الگو، دقت بالاتری از انقضای زمانی دارد چون روی زمینه تمرکز می‌کند نه زمان.

الگوی سوم: انقضای وابسته

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

الگوی چهارم: انقضای دستی

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

الگوی پنجم: انقضای دو لایه

داده موقت هم یک لایه انقضای زمانی و هم یک لایه انقضای رویدادمحور دارد. هر کدام که اول برسد، داده را بی‌اعتبار می‌کند. این الگو، امن‌ترین رویکرد از نظر پایداری است ولی پیاده‌سازی پیچیده‌تری دارد. در پروژه‌های بزرگ، من این الگو را برای داده‌های حساس به کار می‌برم.

هر داده موقت، یک قرارداد انقضا دارد؛ نداشتن قرارداد، به‌معنی انبار شدن دائمی و کندی تدریجی است.

autoload_options؛ انبار پنهانی که هر بازدید را سنگین می‌کند

یکی از پنهان‌ترین مشکلات داده موقت در وردپرس، ستون autoload در جدول wp_options است. وقتی یک option با مقدار autoload فعال ذخیره می‌شود، وردپرس در هر درخواست، آن option را از دیتابیس می‌خواند و در حافظه لود می‌کند — حتی اگر همان درخواست، به آن option نیازی نداشته باشد. این رفتار، برای سایت‌های کوچک مشکلی نیست ولی در سایت‌هایی با هزاران ردیف autoload، تبدیل به یک عامل سنگین پنهان می‌شود.

کوئری ساده برای شمارش حجم autoload

SELECT COUNT(*) AS total,
       ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS size_mb
FROM wp_options
WHERE autoload = 'yes';

اگر خروجی این کوئری بیشتر از یک مگابایت باشد، سایت شما در هر بازدید، چند صد میلی‌ثانیه اضافه صرف خواندن optionهای بی‌نیاز می‌کند. برای سایت‌های وردپرسی معمولی، حجم سالم autoload زیر ۸۰۰ کیلوبایت است. در پروژه‌ای که دیتابیس بزرگ آن را بررسی کردم، خروجی این کوئری ۳.۴ مگابایت بود و علت، یک افزونه بود که در هر به‌روزرسانی، ردیف جدیدی با autoload اضافه می‌کرد و ردیف‌های قدیمی را پاک نمی‌کرد.

الگوی درست ذخیره option

قاعده‌ای که در همه افزونه‌های خودم رعایت می‌کنم: optionهایی که در هر درخواست لازم نیستند، با autoload صریح ذخیره نشوند. وردپرس از نسخه ۶.۶ به بعد، این امکان را می‌دهد که مقدار autoload را به‌صورت صریح در تابع update_option تعیین کنید:

update_option( 'myplugin_last_sync_time', time(), false );

پارامتر سوم این تابع، مقدار autoload را کنترل می‌کند. برای داده‌های موقت مثل زمان آخرین Sync، مقدار false انتخاب درست است. برای تنظیمات اصلی افزونه که در هر درخواست لازم است، مقدار true منطقی است. این تفکیک، در سایت‌های پرترافیک اثر مستقیم روی سرعت سایت دارد و یکی از اصولی است که در ساختار استاندارد یک افزونه حرفه‌ای وردپرس به‌عنوان یک ستون معماری معرفی کرده‌ام.

پاک‌سازی ردیف‌های autoload قدیمی

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

SELECT option_name, LENGTH(option_value) AS size_bytes
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size_bytes DESC
LIMIT 30;

این کوئری، سی option بزرگ‌ترین را نشان می‌دهد. اگر نام optionها به افزونه‌ای اشاره کند که دیگر نصب نیست، کاندید حذف است. ولی هشدار مهم: پیش از هر حذف، یک بکاپ از دیتابیس بگیرید. optionهایی که با پیشوندهای هسته وردپرس (_transient_، theme_mods_، و مشابه) هستند، معمولاً نباید حذف شوند چون ممکن است سایت به آن‌ها وابسته باشد.

Revision، Trash و Auto-draft: سایه‌های محتوا

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

محدود کردن تعداد Revision

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

define( 'WP_POST_REVISIONS', 5 );

این ثابت باعث می‌شود هر نوشته حداکثر پنج نسخه قبلی داشته باشد و نسخه‌های قدیمی‌تر به‌طور خودکار حذف شوند. در پروژه‌های واقعی، تنظیم این ثابت روی اعداد بین ۳ تا ۵، تعادلی بین امکان بازیابی و مصرف دیسک ایجاد می‌کند. برای بلاگ‌های پرمحتوای تیمی، عدد بالاتر منطقی است؛ برای سایت‌های شرکتی که محتوای‌شان ماهانه به‌روزرسانی می‌شود، حتی ۲ کافی است.

Auto-draft و Trash: انبار نامرئی

هر بار که کاربر صفحه ویرایش نوشته را در پیشخوان باز می‌کند، وردپرس یک ردیف Auto-draft ایجاد می‌کند. اگر کاربر بدون ذخیره صفحه را ببندد، این Auto-draft به‌عنوان یک ردیف یتیم باقی می‌ماند. در سایتی با چند نویسنده که روزانه چندین بار ویرایشگر را باز می‌کنند، این ردیف‌ها سریع جمع می‌شوند. Trash هم مشابه است: نوشته‌های حذف‌شده تا سی روز در Trash باقی می‌مانند و بعد از آن به‌طور خودکار حذف می‌شوند — ولی اگر سایت شما Cron را روی حالت غیرفعال داشته باشد، این پاک‌سازی خودکار انجام نمی‌شود.

کوئری شمارش ردیف‌های سایه

SELECT post_status, COUNT(*) AS total
FROM wp_posts
WHERE post_status IN ( 'revision', 'auto-draft', 'trash' )
GROUP BY post_status;

اگر خروجی این کوئری، عدد revision بزرگ‌تر از مجموع نوشته‌های منتشرشده بود، یعنی سایت شما بیشتر از محتوا، سایه محتوا دارد. این وضعیت در پروژه‌های چندساله که هیچ‌وقت پاک‌سازی نشده‌اند، رایج است.

داده‌های موقت مرتبط با کاربر

داده‌های مرتبط با کاربر، حساس‌ترین دسته داده موقت است. سه نوع اصلی این داده در وردپرس وجود دارد: Sessionهای سایت، Tokenهای موقت احراز هویت و داده‌های موقت پروفایل. مدیریت این داده‌ها باید هم‌زمان به امنیت و به عملکرد توجه کند.

Sessionهای وردپرس

وردپرس به‌طور پیش‌فرض از Sessions در معنای سنتی PHP استفاده نمی‌کند، بلکه بر پایه کوکی‌های احراز هویت کار می‌کند. ولی افزونه‌های زیادی — مخصوصاً افزونه‌های فروشگاهی و عضویت — از Sessionهای خودساخته استفاده می‌کنند که معمولاً در wp_usermeta یا wp_options ذخیره می‌شوند. اگر این Sessionها انقضا نداشته باشند، به مرور تبدیل به داده‌های موقتی می‌شوند که هیچ‌وقت پاک نمی‌شوند. الگوی درست این است که Session با هر فعالیت کاربر تمدید شود و پس از یک بازه بی‌فعالیت، به‌طور خودکار حذف شود. اصول دقیق این کار در کار با User Meta در کدنویسی وردپرس و امن‌سازی نشست‌های کاربری آمده است.

Tokenهای موقت

Tokenهای احراز هویت — مثل Tokenهای بازیابی رمز عبور یا Tokenهای یک‌بارمصرف ورود — داده‌های موقتی هستند که اگر پاک نشوند، ریسک امنیتی ایجاد می‌کنند. هر Token باید یک بازه انقضای مشخص داشته باشد و بعد از استفاده، صریحاً بی‌اعتبار شود. اگر روی سیستم احراز هویت کار می‌کنید، JWT چیست و چه کاربردی در احراز هویت دارد و احراز هویت دو مرحله‌ای چگونه امنیت را افزایش می‌دهد دو مرجع مرتبط هستند.

Nonceها و داده‌های موقت امنیتی

Nonceها در وردپرس یک نوع خاص داده موقت امنیتی هستند که عمرشان معمولاً ۲۴ ساعت است. وردپرس این Nonceها را در صورت لزوم بازسازی می‌کند ولی در عمل، ردیف‌های غیرفعال باقی می‌مانند. برای درک کامل این لایه، نانس وردپرس و نقش آن در امنیت فرم‌ها راهنمای دقیقی است. به‌طور خلاصه، Nonceها نباید دست‌کاری مستقیم شوند ولی باید به‌عنوان بخشی از بودجه داده موقت در پاک‌سازی دیتابیس در نظر گرفته شوند.

یک نکته عملی که در پروژه‌های واقعی به آن رسیده‌ام: هنگام پاک‌سازی User Meta، هرگز نباید ردیف‌های Nonce و Session را با کوئری خام حذف کرد، چون ممکن است کاربران فعال را از سیستم خارج کند. این پاک‌سازی باید فقط از طریق API خود وردپرس یا افزونه‌ای که مالک این داده‌ها است انجام شود.

داده‌های یتیم: آنچه از افزونه‌های حذف‌شده جا می‌ماند

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

سه منبع اصلی داده یتیم

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

روش شناسایی داده یتیم

روش دقیقی که در پروژه‌های بزرگ استفاده می‌کنم، ترکیبی از دو کوئری است. اول، شمارش ردیف‌ها بر اساس پیشوند کلید:

SELECT SUBSTRING_INDEX(meta_key, '_', 1) AS prefix, COUNT(*) AS total
FROM wp_postmeta
GROUP BY prefix
ORDER BY total DESC
LIMIT 40;

دوم، تطبیق این پیشوندها با افزونه‌های فعال. اگر پیشوندی در این فهرست هست ولی به هیچ افزونه فعالی اشاره نمی‌کند، به‌احتمال زیاد از یک افزونه حذف‌شده به‌جا مانده است. این روش در پروژه‌ای با پیشوند _wprm_ (مربوط به افزونه Recipe Maker که سال‌ها پیش حذف شده بود) حدود ۸۰ هزار ردیف یتیم را شناسایی کرد که مجموعاً ۲۲۰ مگابایت فضای دیتابیس را اشغال کرده بودند.

حذف داده یتیم، با احتیاط

حذف داده یتیم، جراحی دقیق می‌طلبد. در همه پروژه‌ها ابتدا یک بکاپ کامل از دیتابیس می‌گیرم و بعد از حذف، حتماً سایت را در محیط staging به‌طور کامل تست می‌کنم. برای درک بهتر تفاوت‌های محیط production و staging، توسعه وردپرس با محیط لوکال چگونه انجام می‌شود روش راه‌اندازی را توضیح می‌دهد.

داده یتیم را نباید از روی حدس حذف کرد؛ هر ردیف یتیم باید پیش از حذف، با نام افزونه‌ای که مالکش بود، تطبیق داده شود.

الگوهای امن پاک‌سازی

حالا که انواع داده موقت را می‌شناسید، برویم سراغ پاک‌سازی. سه اصل که در همه پروژه‌ها رعایت می‌کنم:

اصل اول: بکاپ قبل از هر پاک‌سازی

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

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

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

DELETE FROM wp_postmeta
WHERE meta_key LIKE '_orphan_plugin_%'
LIMIT 500;

این کوئری، حداکثر ۵۰۰ ردیف در هر اجرا حذف می‌کند. با اجرای دوره‌ای این کوئری در یک Cron، در چند ساعت همه داده‌ها پاک می‌شود بدون اینکه سایت دچار وقفه محسوس شود. جزئیات راه‌اندازی این Cron در کرون وردپرس و زمان‌بندی خودکار کارها آمده است.

اصل سوم: اولویت‌بندی بر اساس ریسک

در پروژه‌های واقعی، ابتدا داده‌هایی را پاک می‌کنم که ریسک‌شان پایین است (Transientهای منقضی، Auto-draftهای بیش از ۳۰ روزه) و در مرحله بعد سراغ داده‌هایی می‌روم که ریسک بیشتری دارند (User Meta و Post Meta یتیم). این ترتیب، ریسک کلی را کم می‌کند و فرصت می‌دهد تا قبل از هر مرحله، اثر مرحله قبل را روی سایت بسنجید.

پایش و اندازه‌گیری حجم داده موقت

پاک‌سازی یک‌باره، گام اول است؛ ولی برای جلوگیری از انبار شدن مجدد، پایش دوره‌ای ضروری است. چهار شاخص که در همه پروژه‌ها روی آن‌ها نظارت می‌کنم:

شاخص اول: نسبت داده موقت به محتوا

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

SELECT
    ( SELECT COUNT(*) FROM wp_posts
      WHERE post_status IN ( 'revision', 'auto-draft' ) ) AS temp_posts,
    ( SELECT COUNT(*) FROM wp_posts
      WHERE post_status = 'publish' ) AS published_posts;

اگر نسبت temp_posts به published_posts بزرگ‌تر از ۵۰ درصد شد، وقت پاک‌سازی است.

شاخص دوم: حجم autoload options

همان کوئری که در بخش autoload دیدیم، باید ماهانه اجرا شود. اگر حجم از ۸۰۰ کیلوبایت فراتر رفت، علت را با دیدن بزرگ‌ترین optionها شناسایی کنید. این پایش، یک عادت ماهانه است که در بلندمدت تفاوت محسوس در سرعت سایت ایجاد می‌کند.

شاخص سوم: تعداد Cronهای فعال

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

شاخص چهارم: رشد ماهانه دیتابیس

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

پرسش‌های پرتکرار درباره مدیریت داده موقت وردپرس

تفاوت داده موقت و داده کش چیست؟ کش یک زیرمجموعه از داده موقت است. هر کش، داده موقت است ولی برعکس آن صادق نیست. مثلاً یک Cron رویداد، داده موقت است ولی کش نیست. مدیریت داده موقت، قاب بزرگ‌تری است که کش را هم شامل می‌شود.

آیا پاک‌سازی داده موقت روی سئو اثر دارد؟ بله، به‌طور غیرمستقیم. وقتی دیتابیس سبک‌تر می‌شود، زمان پاسخ سرور کاهش می‌یابد و این در Core Web Vitals (شاخص‌های اصلی وب) خودش را نشان می‌دهد. اگر می‌خواهید ارتباط این دو را دقیق‌تر ببینید، چگونه سرعت سایت بر سئو تاثیر می‌گذارد را بخوانید.

چرا ترنزینت‌های من بعد از انقضا پاک نمی‌شوند؟ در محیط بدون Object Cache، ترنزینت‌های منقضی به‌طور خودکار حذف نمی‌شوند و به‌عنوان ردیف در wp_options باقی می‌مانند. برای پاک‌سازی خودکار، یک Cron دوره‌ای نیاز است. الگوی دقیق این Cron در ترنزینت وردپرس چیست و چگونه کش هوشمند بدون افزونه بسازیم آمده است.

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

چگونه بفهمم کدام داده یتیم است؟ تطبیق پیشوند option و meta key با افزونه‌های فعال، روش استانداردی است. اگر رویه‌ای روتین برای این کار می‌خواهید، فهرست افزونه‌های بهینه‌سازی دیتابیس که در مقاله مربوطه آورده‌ام، ابزارهای مناسبی برای این کار دارند. ولی هشدار مهم: هیچ ابزاری نباید بدون بکاپ اجرا شود.

آیا باید داده موقت را در staging یا production پاک کنم؟ همیشه در staging. الگوی من این است: در staging پاک‌سازی انجام می‌دهم، سایت را چند روز تست می‌کنم و اگر مشکلی نبود، همان کوئری‌ها را در production اجرا می‌کنم. راه‌اندازی staging در توسعه وردپرس با محیط لوکال چگونه انجام می‌شود توضیح داده شده است.

آیا Object Cache مشکل داده یتیم را حل می‌کند؟ نه، فقط بخشی از آن را کاهش می‌دهد. Object Cache باعث می‌شود ترنزینت‌های منقضی به‌طور خودکار حذف شوند، ولی سایر انواع داده یتیم — مثل metaهای بی‌مصرف و Cronهای جامانده — در Object Cache هم باقی می‌مانند. پاک‌سازی دوره‌ای، همچنان ضروری است.

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

چند وقت یک بار پاک‌سازی داده موقت انجام دهم؟ برای سایت‌های محتوایی کوچک، هر سه ماه کافی است. برای سایت‌های فروشگاهی یا پرمحتوای تیمی، ماهانه. برای سایت‌های چندنویسنده با محتوای روزانه، حتی هر دو هفته. پایش ماهانه سبک — فقط اجرای چهار کوئری — به شما نشان می‌دهد که آیا وقت پاک‌سازی رسیده یا نه.

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

انبار موقت را مثل انبار فیزیکی مدیریت کنید

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

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

اگر در ابتدای مسیر یادگیری هستید، سه تمرین را پیشنهاد می‌کنم. اول، روی یک سایت تستی با هزار ردیف Transient، کوئری‌های پاک‌سازی این مقاله را اجرا کنید و اثرشان روی سرعت را بسنجید. دوم، در یک Cron هفتگی، شمارش خودکار revision و autoload را فعال کنید و لاگ بگیرید تا ترند را در سه ماه ببینید. سوم، یک بار در محیط staging، پاک‌سازی کامل انجام دهید و اثرش را در ابزارهای تست سرعت بسنجید — این تجربه، درک عمیقی از هزینه پنهان داده موقت به شما می‌دهد که هیچ مقاله‌ای جایگزینش نمی‌شود.

اگر تجربه‌ای از پاک‌سازی دیتابیس در پروژه‌ای واقعی دارید — چه موفق، چه پر از دام — در دیدگاه بنویسید. آن تجربه برای کسی که همین امروز تصمیم می‌گیرد پاک‌سازی دیتابیس سایت مشتری‌اش را شروع کند یا نه، ارزشمندتر از هر مستند رسمی است. 🗃️