DirectAdmin جای بررسی موتور دیتابیس و بار واقعی برنامه را نمی‌گیرد. کپی فایل‌های قدیمی my-large.cnf یا my-huge.cnf روی پیکربندی سرور، نسخه و مصرف منابع را در نظر نمی‌گیرد و می‌تواند سرویس را مختل کند.
اول علت کندی را مشخص کنید
نسخهٔ MySQL یا MariaDB، موتور جدول‌ها، حجم داده و زمان کندی را ثبت کنید. کندی یک صفحه ممکن است از کوئری، نبود ایندکس مناسب، قفل، دیسک یا پردازش برنامه بیاید. مدیر می‌تواند با ثبت کنترل‌شدهٔ slow query log، کوئری‌های مسئله‌دار را پیدا کند؛ لاگ به‌تنهایی آن‌ها را بهینه نمی‌کند.
کاربر هاست اشتراکی معمولاً اختیار تنظیم سراسری دیتابیس را ندارد. نام دیتابیس، زمان رخداد و نمونهٔ درخواست کند را به میزبان بدهید. اطلاعات مشتری و کوئری‌های حاوی دادهٔ حساس را در گزارش عمومی منتشر نکنید.
تنظیم حافظه برای مدیر مجاز
در MySQL با InnoDB، buffer pool داده و ایندکس را در حافظه نگه می‌دارد. اندازهٔ مناسب به حافظهٔ قابل استفادهٔ دیتابیس، سایر فرایندها و بار بستگی دارد؛ سرور مشترک وب و دیتابیس با سرور اختصاصی دیتابیس نیاز یکسان ندارد. آستانهٔ ثابت «بیش از دو گیگابایت یعنی huge» مبنای مناسبی نیست.
- پیکربندی فعلی و خط مبنا را ثبت و بکاپ قابل بازیابی را کنترل کنید.
- تنظیم کوچک و مستند متناسب با موتور و نسخه را در بازهٔ نگهداری آزمایش کنید.
- مصرف حافظه، زمان پاسخ و خطاها را با بار مشابه بسنجید و امکان برگشت را حفظ کنید.
OPTIMIZE TABLE چه کاری می‌کند؟
در MySQL 8.4، رفتار این دستور به موتور بستگی دارد؛ برای InnoDB بازسازی جدول انجام می‌شود و شرایط فضای دیسک و قفل‌ها اهمیت دارند. این عملیات جای اصلاح کوئری کند نیست. اجرا روی همهٔ جدول‌ها یا زمان‌بندی کورکورانه می‌تواند هزینه ایجاد کند. راهنمای MySQL را بدون بررسی به MariaDB تعمیم ندهید؛ گزینه‌ها و رفتار نسخه‌ها متفاوت‌اند.
سرویس‌های مرتبط با این مطلب
برای بررسی راهکار مناسب، مشخصات و شرایط این خدمات را ببینید.
