رشد دیتابیس طبیعی است، اما داده‌های موقت و کارهای زمان‌بندی‌شده هم می‌توانند سهم مهمی داشته باشند.
حجم را به بخش‌های کوچک‌تر تقسیم کنید
حجم جدول‌ها و روند رشد آن‌ها را ثبت کنید. سفارش‌ها، نشست‌ها، لاگ‌ها و داده افزونه‌ها وظایف متفاوتی دارند. قبل از پاک‌سازی مشخص کنید هر جدول متعلق به کدام بخش است. حذف کورکورانه جدول یا متادیتا ممکن است اطلاعات سفارش یا تنظیمات افزونه را از بین ببرد.
پاک‌سازی قابل بازگشت
از ابزار رسمی افزونه و تنظیمات نگهداری لاگ استفاده کنید. هر تغییر را ابتدا روی کپی دیتابیس امتحان کنید و بکاپ قابل بازیابی نگه دارید. برای فروشگاه‌های بزرگ، زمان اجرای پاک‌سازی و تاثیر قفل‌های دیتابیس مهم است. کاهش حجم لزوما به معنی سریع‌تر شدن همه کوئری‌ها نیست.
برای انتخاب یا تغییر زیرساخت، ابتدا وضعیت فعلی سایت را ثبت کنید. یک تغییر مشخص انجام دهید و سپس همان مسیرهای کاربری را دوباره آزمایش کنید. راهنماهای روناتا مبنای تصمیم‌گیری اولیه هستند و بررسی جزئیات هر سایت به داده واقعی نیاز دارد.
اندازه جدول را با وظیفه آن تفسیر کنید
دیتابیس فروشگاه با سفارش، کاربر، نشست و وظایف پس‌زمینه رشد می‌کند. جدول بزرگ به‌تنهایی نشانه داده اضافی نیست. نام جدول، نقش افزونه، نرخ رشد و زمان کوئری را کنار هم بررسی کنید. جدول سفارش یا داده مالی را صرفا به دلیل حجم بالا خالی نکنید. پیش از هر پاک‌سازی، نسخه مستقل تهیه کنید و روش بازگشت را در محیط جدا بسنجید.
فعال بودن HPOS را از تنظیمات ووکامرس بررسی کنید. محل اصلی ذخیره سفارش به وضعیت این قابلیت و سازگاری افزونه‌ها وابسته است. نباید فرض کرد تمام فروشگاه‌ها فقط از posts و postmeta برای سفارش استفاده می‌کنند. مستندات رسمی HPOS درباره ساختار و سازگاری توضیح می‌دهد. برای تغییر حالت، وضعیت همگام‌سازی و افزونه‌های وابسته باید بررسی شود.
صف کار و نشست را از داده سفارش جدا کنید
Action Scheduler کارهای پس‌زمینه را نگه می‌دارد. تعداد زیاد کار ناموفق ممکن است نشانه خطای افزونه، Cron یا محدودیت اجرای کار باشد. حذف صف بدون شناخت علت می‌تواند کار ضروری را از دسترس خارج کند و تولید مجدد خطا ادامه یابد. نوع hook، زمان اجرا و پیام شکست را بررسی کنید. اول علت توقف یا تکرار را رفع کنید، سپس نگهداری داده را طبق روش پشتیبانی‌شده انجام دهید.
نشست‌های منقضی، لاگ‌های افزونه و transientها نیز سیاست نگهداری دارند. عبارت حذف همه داده اضافی، محدوده دقیقی نیست. از ابزار همان افزونه یا مستندات رسمی برای پاک‌سازی استفاده کنید. داده‌ای که امروز کاربرد مشخصی ندارد ممکن است برای پیگیری سفارش یا اختلاف لازم باشد. نیاز کسب‌وکار و سیاست نگهداری را قبل از حذف با مسئول فروشگاه هماهنگ کنید.
| داده | سوال قبل از اقدام |
|---|---|
| سفارش | محل اصلی ذخیره و نیاز نگهداری چیست؟ |
| صف وظایف | چرا کارها تکرار یا شکست می‌خورند؟ |
| لاگ | ابزار مالک و مدت نگهداری کدام است؟ |
| نشست | آیا داده منقضی با روش درست پاک می‌شود؟ |
کندی را با اندازه کل دیتابیس یکی ندانید
کوئری بدون ایندکس یا جست‌وجوی پرهزینه ممکن است روی دیتابیس کوچک هم کند باشد. زمان کوئری، تعداد ردیف بررسی‌شده و مسیر درخواست را ببینید. ساخت ایندکس یا اجرای تعمیر جدول باید با شناخت موتور، نسخه و بار انجام شود. عملیات نگهداری ممکن است قفل یا فشار ورودی و خروجی ایجاد کند. زمان کم‌سفارش و نسخه بازگشت را پیش از اجرا مشخص کنید.
اندازه جدول‌ها و زمان پاسخ مسیرهای اصلی را در چند نوبت ثبت کنید. مقایسه یک عدد قبل و بعد از حذف، پایداری رشد را نشان نمی‌دهد. اگر علت تولید داده رفع نشده باشد، حجم دوباره بالا می‌رود. راهنمای Redis برای کش داده قابل استفاده مجدد و راهنمای عملکرد وردپرس برای پیدا کردن گلوگاه مکمل این بررسی هستند.
