بهینه‌سازی دیتابیس ووکامرس به معنی اجرای یک دکمه «Clean» یا حذف جدول‌های بزرگ نیست. سفارش، آیتم سفارش، محصول، variation، session، صف کارها و گزارش‌ها چرخه عمر متفاوتی دارند. ممکن است جدول بزرگی کاملاً سالم باشد و کندی از یک Query پرتکرار یا lock بیاید؛ در مقابل، چند میلیون log قدیمی واقعاً فقط هزینه backup و نگهداری ایجاد کنند.
پاسخ سریع: ابتدا backup قابل restore و clone بسازید. اندازه و نرخ رشد جدول‌ها، Queryهای کند و مسیر کاربری متاثر را ثبت کنید. داده‌ها را بر اساس مالک و سیاست retention دسته‌بندی کنید، سپس پاک‌سازی یا index را روی clone آزمایش کنید. حذف مستقیم سفارش، metadata یا Scheduled Action روی production راه بهینه‌سازی امن نیست.
هدف را قبل از پاک‌سازی مشخص کنید
- کاهش زمان Query یک مسیر مشخص مانند فیلتر محصول
- کاهش رشد backup و زمان restore
- رفع lock یا I/O هنگام import و گزارش‌گیری
- کنترل جدول‌های log، session یا صف با retention روشن
- رفع autoload یا optionهای سنگین در هر request
اگر هدف فقط «کم شدن حجم» باشد، ممکن است داده‌ای حذف شود که هیچ نقشی در کندی ندارد. معیار قبل و بعد باید زمان Query، latency سناریو، I/O و صحت داده تجاری را شامل شود.
Backup باید واقعاً قابل Restore باشد
پیش از عملیات حذف یا schema، از دیتابیس و فایل‌های رسانه نسخه هماهنگ بگیرید. وجود فایل backup کافی نیست؛ restore را در محیط جدا آزمایش و نسخه MySQL/MariaDB، charset و دسترسی‌ها را کنترل کنید. در فروشگاه فعال، فاصله میان backup و عملیات نیز سفارش جدید ایجاد می‌کند؛ برنامه rollback باید تکلیف داده‌های تازه را مشخص کند.
نقشه داده و رشد بسازید
| گروه داده | پرسش لازم | ریسک حذف |
|---|---|---|
| سفارش و آیتم‌ها | الزام مالی/قانونی و integration چیست؟ | از دست رفتن تاریخچه و reconcile |
| محصول و variation | چه reference و ترجمه‌ای دارد؟ | قیمت، URL و موجودی خراب |
| Session و transient | TTL و کاربران فعال چیست؟ | خالی شدن سبد و logout |
| Scheduled Action | مالک hook و وضعیت business چیست؟ | حذف ایمیل، sync یا پرداخت |
| Log و گزارش موقت | retention و نیاز audit چیست؟ | از بین رفتن شواهد incident |
اندازه snapshot را کنار نرخ رشد روزانه یا هفتگی قرار دهید. جدول بزرگ اما ثابت با index مناسب ممکن است کم‌خطرتر از جدول کوچک با رشد انفجاری و Query بدون محدودیت باشد.
Slow Query را به مسیر کاربر وصل کنید
Slow query log، Query Monitor در محیط کنترل‌شده و profiler می‌توانند متن Query، تعداد اجرا، caller و زمان را نشان دهند. Query کند را با URL، نقش کاربر و timestamp مرتبط کنید. راهنمای پیدا کردن Slow Query وردپرس کمک می‌کند یک Query اتفاقی را با bottleneck پرتکرار اشتباه نگیرید.
Execution plan را قبل و بعد بررسی کنید. افزودن index عمومی بدون توجه به predicate، ترتیب ستون و write workload می‌تواند import و ثبت سفارش را کند کند. تغییر schema ابتدا باید روی clone با حجم داده نزدیک production و بار خواندن/نوشتن واقعی آزموده شود.
سفارش‌ها داده اضافی نیستند
سفارش قدیمی ممکن است برای حسابداری، refund، پشتیبانی، گزارش یا تطبیق درگاه لازم باشد. حذف مستقیم order و itemها می‌تواند رابطه با payment، coupon، stock و integration را ناقص کند. retention سفارش باید با سیاست کسب‌وکار و الزام قانونی تعیین شود و archive نیز باید قابلیت بازیابی و دسترسی کنترل‌شده داشته باشد.
HPOS را در طراحی لحاظ کنید
محل ذخیره سفارش به پیکربندی و قابلیت High-Performance Order Storage وابسته است. ابزار یا کدی که فرض می‌کند تمام سفارش‌ها در ساختار قدیمی‌اند ممکن است داده ناقص ببیند. از APIهای پشتیبانی‌شده ووکامرس و گزارش سازگاری افزونه‌ها استفاده کنید. جدول‌های سفارش را دستی sync یا merge نکنید.
Session و Cart را در ساعت فروش پاک نکنید
sessionهای ووکامرس سبد کاربران فعال را نگه می‌دارند. پاک‌سازی گروهی ممکن است خرید در جریان را از بین ببرد. اگر جدول session بزرگ است، ابتدا TTL، cleanup runner، خطای cron و نرخ ساخت session را بررسی کنید. bot یا cache/cookie نادرست می‌تواند session غیرعادی تولید کند؛ حذف نتیجه، producer را اصلاح نمی‌کند.
Transient و Cacheهای منقضی
transient منقضی معمولاً قابل بازتولید است، اما مالک و روش پاک‌سازی اهمیت دارد. افزونه‌های ناشناخته ممکن است داده عملیاتی را با نام cache نگه دارند. ابزار رسمی یا API همان مؤلفه را ترجیح دهید و تعداد محدودی را روی clone آزمایش کنید. پاک کردن تمام optionها با الگوی متنی می‌تواند تنظیم یا lock معتبر را حذف کند.
Autoload و جدول Options
optionهای autoload در requestهای متعدد بارگذاری می‌شوند. حجم، مالک و نیاز واقعی هر رکورد را بررسی کنید. یک blob بزرگ از افزونه حذف‌شده می‌تواند مهم باشد، اما تغییر پرچم یا حذف رکورد بدون شناخت کد مصرف‌کننده خطر دارد. راهنمای بهینه‌سازی دیتابیس وردپرس زمینه عمومی این بخش را تکمیل می‌کند.
Action Scheduler و داده صف
صف شامل pending، running، failed و completed با hook و args متفاوت است. completedهای قدیمی ممکن است طبق retention پاک شوند، اما pending یا failed می‌توانند نماینده عملیات تجاری اجرا‌نشده باشند. ابتدا قدیمی‌ترین action، سرعت ورود/خروج و خطای runner را تحلیل کنید. مقاله معماری Action Scheduler مبنای تصمیم را توضیح می‌دهد.
Logها و Retention
لاگ درگاه، webhook، ایمیل و debug برای incident لازم است ولی نباید نامحدود رشد کند. retention بر اساس حساسیت، نیاز پشتیبانی و ظرفیت تعریف کنید. secret، token، cookie و داده پرداخت نباید وارد log شوند. پیش از حذف، نمونه لازم برای audit و خطاهای باز را نگه دارید و rotation را اصلاح کنید.
Revision، Draft و داده محتوایی
revision زیاد می‌تواند حجم بسازد، اما حذف آن باید با نیاز بازگشت محتوا هماهنگ باشد. محصول و صفحه فروشگاه ممکن است توسط builder یا سیستم ترجمه به revision وابسته باشند. ابتدا شمارش و سن را بررسی کنید؛ retention محدود و دوره‌ای بهتر از حذف یک‌باره بدون کنترل است.
عملیات Optimize Table معجزه نیست
بازسازی یا optimize یک جدول ممکن است در شرایطی فضای آزاد را بازپس گیرد، اما Query بد را اصلاح نمی‌کند و می‌تواند lock، I/O و فضای موقت قابل توجه بخواهد. رفتار دقیق به engine و نسخه دیتابیس وابسته است. قبل از اجرا، فضای آزاد، زمان نگهداری، replication و امکان rollback را بررسی کنید.
Media با دیتابیس یکسان نیست
تصاویر محصول معمولاً در filesystem یا object storage هستند و دیتابیس reference آن‌ها را نگه می‌دارد. حذف attachment یا فایل «بدون استفاده» ممکن است variation، ترجمه یا محتوای قدیمی را بشکند. پاک‌سازی media را پروژه جدا با inventory، reference check و backup در نظر بگیرید.
روند پیشنهادی بهینه‌سازی
- سناریوی کند و معیار پذیرش را تعریف کنید.
- backup کامل را restore-test کنید و clone نزدیک production بسازید.
- جدول‌ها را بر اساس اندازه، رشد، مالک و چرخه عمر فهرست کنید.
- Slow Query، lock و I/O را با timeline درخواست مرتبط کنید.
- retention و پاک‌سازی را برای هر گروه جدا طراحی کنید.
- index یا schema را با plan و workload خواندن/نوشتن آزمایش کنید.
- عملیات را batch، محدود و قابل توقف اجرا کنید.
- صحت سفارش، موجودی، گزارش، Cart و Checkout را کنترل کنید.
معیارهای پس از تغییر
- تعداد و مجموع زمان Query در سناریوی ثابت
- p50/p95 پاسخ و نرخ خطا
- زمان backup و restore
- سرعت import و ثبت سفارش
- رشد روزانه جدول‌های هدف
- درستی گزارش، refund، موجودی و جست‌وجو
اشتباه‌های رایج
- حذف مستقیم داده با SQL
- اعتماد به «یک کلیک پاک‌سازی» بدون preview
- حذف سفارش یا metadata برای کاهش حجم
- ساخت index حدسی روی production
- پاک‌کردن session کاربران فعال
- حذف صف failed/pending بدون شناخت hook
- اجرای نگهداری بدون فضای موقت و rollback
چه زمانی کمک تخصصی لازم است؟
اگر دیتابیس بزرگ با HPOS، integration مالی، هزاران job یا Queryهای کند دارید، عملیات مستقیم می‌تواند داده سفارش را آسیب بزند. پشتیبانی فروشگاه ووکامرس می‌تواند inventory، Query plan، retention و آزمون restore را پیش از هر حذف یا schema change انجام دهد.
پرسش‌های متداول
آیا حجم زیاد دیتابیس حتماً باعث کندی است؟
خیر؛ Query، index، buffer، lock و الگوی دسترسی تعیین‌کننده‌اند. حجم فقط یکی از متغیرهاست.
آیا می‌توان سفارش‌های قدیمی را حذف کرد؟
تنها با سیاست retention، بررسی مالی/قانونی، archive قابل بازیابی و آزمون integrationها؛ حذف کور مناسب نیست.
پاک کردن transientها امن است؟
بسیاری بازتولید می‌شوند، اما مالک و وضعیت انقضا باید مشخص باشد. ابتدا روی clone و با ابزار پشتیبانی‌شده تست کنید.
هر چند وقت یک بار بهینه‌سازی لازم است؟
بر اساس نرخ رشد و metricها، نه تقویم ثابت. مانیتورینگ باید زمان اقدام را نشان دهد.