چرا بهینه‌سازی دیتابیس اغلب سایت را کندتر می‌کند و اشتباهات رایج کدامند؟ | اشتباهات بهینه‌سازی دیتابیس

چند سال پیش، روی پروژه‌ای کار می‌کردم که صاحبش مدعی بود سایت را کند کرده. بررسی که کردم، متوجه شدم به توصیه یکی از افزونه‌های بهینگی، هفته‌ای یک بار OPTIMIZE TABLE روی تمام جدول‌ها اجرا می‌شد. این عملیات در MariaDB روی جداول InnoDB، عملاً بازسازی کامل جدول است؛ روی دیتابیس ۱.۸ گیگابایتی آن پروژه، هر بار حدود دو ساعت طول می‌کشید و در همان بازه، سایت کند و بی‌واکنش بود. صاحب سایت فکر می‌کرد این کار بهینه‌سازی است، در حالی که در واقع هفته‌ای دو ساعت به سایت خودش آسیب می‌زد. این مقاله، حاصل تجربه‌هایی از این جنس است: هفت اشتباه رایج که در پروژه‌های واقعی زیاد دیده‌ام و مکانیزم فنی پشت هرکدام.

چرا بهینه‌سازی دیتابیس می‌تواند سایت را کندتر کند؟

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

دیتابیس MySQL و MariaDB که هسته اصلی وردپرس را تشکیل می‌دهند، هر کدام از دو موتور اصلی دارند: InnoDB و MyISAM. موتور InnoDB که امروز استاندارد وردپرس است، رفتارهای متفاوتی با MyISAM دارد و بسیاری از توصیه‌های بهینه‌سازی قدیمی که برای MyISAM نوشته شده، روی InnoDB نه‌فقط مفید نیست، بلکه می‌تواند مضر باشد. اگر با تفاوت این دو موتور آشنایی کمتری دارید، مقاله تفاوت innodb و myisam بستر کاملی ارائه می‌دهد.

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

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

اشتباه اول: اجرای بی‌دلیل OPTIMIZE TABLE روی InnoDB

رایج‌ترین اشتباه در بهینه‌سازی دیتابیس وردپرس، اجرای دوره‌ای دستور OPTIMIZE TABLE روی تمام جداول است. این توصیه، از دوران MyISAM باقی مانده که در آن، این دستور واقعاً کار مفیدی انجام می‌داد: فایل‌های داده را بازسازی می‌کرد و فضای آزادشده را پس می‌گرفت. اما روی InnoDB، این دستور رفتار کاملاً متفاوتی دارد.

مکانیزم فنی روی InnoDB

وقتی OPTIMIZE TABLE روی یک جدول InnoDB اجرا می‌شود، موتور به‌طور داخلی دستور ALTER TABLE ... FORCE را اجرا می‌کند. این یعنی جدول به‌طور کامل بازسازی می‌شود: یک جدول موقت ساخته می‌شود، همه داده‌ها از جدول اصلی به آن کپی می‌شوند، جدول اصلی حذف می‌شود، و جدول موقت با نام اصلی تغییر نام می‌دهد. این عملیات روی جدول بزرگ، معادل کپی کل جدول است.

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

کِی OPTIMIZE TABLE واقعاً مفید است؟

در سه سناریوی محدود، این دستور واقعاً مفید است:

بعد از حذف انبوه ردیف‌ها (مثلاً حذف نود درصد جدول log یا جدول ترن‌ها).
بعد از تغییرات عمده در ساختار جدول که فضای داخلی زیادی آزاد شده.
بعد از یک حذف فاجعه‌آمیز که جدول را به‌شدت کوچک کرده.

در تجربه‌ام، حذف دوره‌ای این عملیات، در بیش از هشتاد درصد سایت‌ها ضرر دارد. اگر سایت شما روی MariaDB نسخه ۱۰.۶ و بالاتر است، قابلیت جدیدی به نام InnoDB Defragmentation Online وجود دارد که بدون قفل جدول، فضای آزادشده را پس می‌گیرد. جزئیات این تفاوت‌ها در بهینه‌سازی جداول MySQL برای سرعت بیشتر آمده است.

اشتباه دوم: ایندکس‌گذاری افراطی و بدون اندازه‌گیری

ایندکس (Index) که در فارسی گاهی با معادل فهرست هم از آن یاد می‌شود، ساختاری است که سرعت کوئری را بالا می‌برد. اما اضافه کردن ایندکس، رایگان نیست. هر ایندکس، سه هزینه دارد: فضای دیسک اضافی، زمان بیشتر برای عملیات نوشتن، و بار ذهنی برای نگهداری.

مکانیزم درونی ایندکس

در InnoDB، هر ایندکس یک ساختار B-Tree است که به‌طور جداگانه نگهداری می‌شود. هر بار که یک ردیف INSERT یا UPDATE می‌شود، همه ایندکس‌های مرتبط باید هم‌زمان به‌روزرسانی شوند. اگر جدول شما پنج ایندکس دارد، یک عملیات INSERT نه‌فقط یک ردیف در جدول اصلی، بلکه پنج ردیف در پنج ایندکس اضافه می‌کند. در جدول‌هایی که عملیات نوشتن زیاد دارند (مثل wp_postmeta یا جدول‌های log)، این موضوع به‌سرعت به گلوگاه تبدیل می‌شود.

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

رویکرد درست ایندکس‌گذاری

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

یک قانون سرانگشتی که در پروژه‌های خودم استفاده می‌کنم: هیچ ایندکسی بدون سنجش قبل و بعد اضافه نمی‌شود. اگر اضافه کردن ایندکس، زمان اجرای یک کوئری را از یک ثانیه به ۵۰ میلی‌ثانیه کاهش دهد اما زمان INSERT را از ۵ میلی‌ثانیه به ۲۰ میلی‌ثانیه برساند، هنوز برنده هستیم. اما اگر کوئری بهینه‌شده به‌ندرت اجرا می‌شود و INSERT به‌طور مکرر، آن‌وقت ایندکس، ضرر خالص است.

اشتباه سوم: پاک‌سازی اسپم و ترن‌ها به‌شکل غیرسازمانی

پاک‌سازی اسپم، ترن‌ها (Transient) و داده‌های موقت، یکی از پرتکرارترین توصیه‌های بهینه‌سازی دیتابیس است. اما این پاک‌سازی هم اگر اشتباه انجام شود، می‌تواند مشکل جدی ایجاد کند.

نقش ترن‌ها در وردپرس

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

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

پاک‌سازی اسپم دیدگاه‌ها

برای اسپم دیدگاه‌ها، حذف به‌شکل دسته‌ای از پیشخوان وردپرس کافی است. اما در تجربه‌ام، حذف مستقیم با کوئری SQL روی جدول wp_comments بدون در نظر گرفتن جدول wp_commentmeta، به داده‌های یتیم (Orphan Data) تبدیل می‌شود که به‌مرور جدول‌های شما را سنگین می‌کند. اگر با ساختار جدول‌های وردپرس آشنایی کمتری دارید، مقاله بهینه‌سازی دیتابیس وردپرس چیست ساختار را توضیح می‌دهد.

روش درست: همیشه همراه حذف ردیف‌های اصلی، ردیف‌های meta مرتبط را هم پاک کنید. در وردپرس، توابع استاندارد مثل wp_delete_comment() این کار را خودکار انجام می‌دهند. اگر با SQL دستی کار می‌کنید، حتماً JOIN بین جدول اصلی و meta را لحاظ کنید.

اشتباه چهارم: نادیده گرفتن autoload در wp_options

یکی از پنهان‌ترین اشتباهات بهینه‌سازی دیتابیس وردپرس، نادیده گرفتن ستون autoload در جدول wp_options است. این ستون، در واقع یکی از مهم‌ترین عوامل تأثیرگذار بر سرعت وردپرس است و در بیشتر مقالات بهینه‌سازی به آن اشاره نمی‌شود.

مکانیزم autoload

ستون autoload مشخص می‌کند کدام گزینه‌ها در هر درخواست PHP، به‌طور خودکار بارگذاری شوند. هر ردیفی که مقدار autoload آن yes است، در هر بازدید سایت، از دیتابیس خوانده می‌شود و در حافظه PHP قرار می‌گیرد. در یک سایت وردپرسی معمولی، این تعداد ممکن است بین ۵۰ تا ۲۰۰ ردیف باشد. اما در سایت‌های قدیمی که افزونه‌های متعددی نصب و حذف شده‌اند، این عدد می‌تواند به هزاران ردیف برسد.

در پروژه‌ای که اخیراً بررسی کردم، ستون autoload در جدول wp_options بیش از ۴ مگابایت داده داشت. یعنی هر بازدید سایت، چهار مگابایت داده فقط از روی این ستون خوانده می‌شد. این حجم، مستقیماً روی TTFB (Time To First Byte - زمان تا اولین بایت) اثر می‌گذاشت و سایت را کند می‌کرد. اگر با مفهوم TTFB آشنایی کمتری دارید، تأثیر TTFB بر سرعت بارگذاری صفحه تحلیل دقیقی ارائه می‌دهد.

روش درست مدیریت autoload

سه قدم برای مدیریت autoload:

با کوئری زیر، اندازه کل داده‌های autoload را بشمارید:
```
SELECT SUM(LENGTH(option_value)) 
FROM wp_options 
WHERE autoload = 'yes';
```
گزینه‌هایی که به‌ندرت استفاده می‌شوند را به autoload = 'no' تغییر دهید.
گزینه‌های یتیم (متعلق به افزونه‌های حذف‌شده) را کاملاً پاک کنید.

در تجربه‌ام، مدیریت درست autoload در سایت‌های چندساله، به‌طور متوسط ۲۰ تا ۴۰ درصد TTFB را کاهش می‌دهد. این بهینه‌سازی، از هر افزونۀ بهینگی مؤثرتر و پایدارتر است. اصول کامل این حوزه در چگونه دیتابیس وردپرس را پاک‌سازی کنیم و بهترین افزونه‌های بهینه‌سازی دیتابیس وردپرس آمده است.

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

اشتباه پنجم: حذف بی‌محافظه‌کارانه ریویژن‌ها و پیامدهای مخفی

ریویژن‌ها (Revisions) که در فارسی گاهی با معادل بازنگری‌ها یا نسخه‌های قبلی از آن‌ها یاد می‌شود، نسخه‌های قبلی نوشته‌ها هستند که وردپرس به‌طور خودکار ذخیره می‌کند. این ریویژن‌ها در جدول wp_posts ذخیره می‌شوند و در سایت‌های پرنویسنده، می‌توانند فضای قابل توجهی اشغال کنند.

مشکل اصلی ریویژن‌ها

در سایت‌های با نویسندگان متعدد، تعداد ریویژن‌ها می‌تواند از تعداد نوشته‌های اصلی بیشتر شود. یعنی اگر سایت شما هزار نوشته دارد، ممکن است پنج هزار ریویژن هم داشته باشد. این پنج هزار ردیف اضافه، به‌طور جدی روی سرعت کوئری‌های جدول wp_posts اثر می‌گذارد.

اما اشتباه رایج، حذف کورکورانه همه ریویژن‌ها است. سه پیامد پنهان در این کار وجود دارد:

از دست دادن تاریخچه تغییرات: اگر روزی نیاز داشتید نسخه قبلی یک نوشته را ببینید، دیگر وجود ندارد.
یتیم شدن داده‌های meta: ریویژن‌ها هم در جدول wp_postmeta داده دارند. حذف ناقص، داده‌های یتیم ایجاد می‌کند.
مشکل در سایت‌های چندنویسنده: در تیم‌های تحریریه، ریویژن‌ها بخشی از جریان کاری هستند.

رویکرد درست

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

define( 'WP_POST_REVISIONS', 5 );

این تنظیم، حداکثر پنج نسخه قبلی از هر نوشته را نگه می‌دارد. برای حذف ریویژن‌های قدیمی موجود، از افزونه‌های معتبر یا کوئری‌های SQL دقیق استفاده کنید که هم ردیف‌های wp_posts و هم ردیف‌های مرتبط در wp_postmeta را پاک کنند. جزئیات کامل در رول‌بک و ریویژن‌ها چگونه دیتابیس را سنگین می‌کنند آمده است.

اشتباه ششم: نصب افزونه‌های بهینگی بدون درک عملکردشان

افزونه‌های بهینگی دیتابیس، ابزارهایی هستند که ادعا می‌کنند به‌طور خودکار دیتابیس را بهینه می‌کنند. اما در تجربه‌ام، بیشتر این افزونه‌ها کاری که انجام می‌دهند، دقیقاً همان کارهایی است که در اشتباهات قبلی توضیح داده شد: OPTIMIZE TABLE، حذف ترن‌ها، حذف ریویژن‌ها، همه با یک دکمه.

عملیات پرخطر افزونه‌های بهینگی

سه عملیات پرخطر که در افزونه‌های بهینگی زیاد دیده‌ام:

حذف خودکار ترن‌ها: افزونه‌هایی که ترن‌های منقضی‌شده را پاک می‌کنند، اگر تنظیماتشان اشتباه باشد، ترن‌های فعال را هم پاک می‌کنند.
بهینه‌سازی خودکار جداول: اجرای دوره‌ای OPTIMIZE TABLE بدون درک پیامدهایش.
حذف خودکار داده‌های اضافه: بعضی افزونه‌ها داده‌هایی که به‌نظرشان اضافه است را پاک می‌کنند، بدون اینکه بدانند آن داده‌ها در واقع بخشی از عملکرد یک افزونه فعال است.

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

افزونه‌های بهینگی دیتابیس، ابزارهایی مفید هستند اگر با درک استفاده شوند. سه قانون که برای خودم گذاشته‌ام:

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

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

اشتباه هفتم: بهینه‌سازی بدون اندازه‌گیری قبل و بعد

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

چهار عددی که باید قبل از هر بهینه‌سازی ثبت کنید

پیش از هر عملیات بهینه‌سازی، این چهار عدد را ثبت کنید:

شاخص	روش اندازه‌گیری	هدف
زمان بارگذاری صفحه اصلی	ابزار تست سرعت یا curl	ثبت عدد پایه
حجم دیتابیس	پنل هاست یا phpMyAdmin	سنجش اثر
TTFB	DevTools یا curl	سنجش مستقیم سرور
زمان اجرای کوئری سنگین	EXPLAIN یا Slow Query Log	سنجش دقیق دیتابیس

بعد از هر عملیات، همین چهار عدد را دوباره بگیرید و با قبل مقایسه کنید. اگر بهبود محسوس نبود، آن عملیات را کنار بگذارید. اگر بدتر شد، بازگردانی کنید. اگر بهتر شد، ثبت کنید که چه چیزی مؤثر بوده، تا در آینده به همان روش تکیه کنید.

ابزارهای اندازه‌گیری

در تجربه‌ام، سه ابزار برای این کار کافی است: ابزار تست سرعت مثل PageSpeed Insights یا GTmetrix برای سنجش ظاهری، DevTools مرورگر برای سنجش دقیق TTFB، و MySQL Slow Query Log برای سنجش کوئری‌های کند. اگر با فرآیند سنجش سرعت آشنایی کمتری دارید، ابزارهای تست سرعت سایت راهنمای جامعی ارائه می‌دهد.

یک نکته تجربی مهم: برای مقایسه دقیق، همیشه در شرایط یکسان اندازه‌گیری کنید. اگر قبل از بهینه‌سازی، ساعت ۱۰ صبح یک روز را اندازه گرفتید و بعد از بهینه‌سازی ساعت ۹ شب روز دیگر، مقایسه‌تان بی‌اعتبار است. چون ترافیک سایت، بار سرور، و حتی رفتار کش در ساعات مختلف متفاوت است. این جزئیات کوچک، تفاوت بین یک اندازه‌گیری قابل‌اعتماد و یک نتیجه‌گیری غلط است.

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

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

گام اول: تشخیص دقیق

پیش از هر عملیات، باید بدانید مشکل واقعی دیتابیس شما چیست. سه سؤال کلیدی:

کدام کوئری‌ها کند هستند؟ (با Slow Query Log)
کدام جدول‌ها بزرگ‌تر هستند؟ (با کوئری اطلاعات)
کدام شاخص‌ها ضعیف هستند؟ (با اندازه‌گیری)

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

گام دوم: تعیین اولویت‌ها

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

گام سوم: اجرای محتاطانه

هر عملیات را یکی‌یکی انجام دهید، نه همه را با هم. بین هر عملیات، اندازه‌گیری کنید. اگر عملیات اول بهبود داد، سراغ دومی بروید. اگر نه، قبل از عملیات بعدی، ابتدا عملیات قبلی را کامل تحلیل کنید.

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

گام چهارم: پایش مستمر

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

بهینه‌سازی دیتابیس در بستر معماری

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

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

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

چه زمانی واقعاً باید OPTIMIZE TABLE اجرا کنم؟

فقط در سه سناریو: بعد از حذف انبوه ردیف‌ها (بیش از ۳۰ درصد جدول)، بعد از تغییرات عمده ساختار جدول، و بعد از یک حذف فاجعه‌آمیز. در غیر این صورت، این دستور روی InnoDB، بیشتر ضرر دارد تا سود. اگر سایت شما روی MariaDB ۱۰.۶ یا بالاتر است، به‌جای این دستور از InnoDB Defragmentation Online استفاده کنید که بدون قفل جدول کار می‌کند.

چند ایندکس روی هر جدول مناسب است؟

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

آیا باید ترن‌ها را پاک کنم؟

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

DELETE FROM wp_options WHERE option_name LIKE '%_transient_timeout_%' AND option_value < UNIX_TIMESTAMP();

مقدار مناسب autoload در wp_options چقدر است؟

هیچ عدد مطلقی وجود ندارد، اما یک معیار عملی: مجموع حجم داده‌های autoload نباید بیش از ۱ مگابایت باشد. اگر بیشتر است، باید بررسی کنید کدام گزینه‌ها نیازی به autoload ندارند و به no تغییرشان دهید. در تجربه‌ام، در سایت‌های چندساله، مجموع حجم autoload می‌تواند به ۵ تا ۱۰ مگابایت برسد که این حجم در هر بازدید سایت از دیتابیس خوانده می‌شود.

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

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

همه ریویژن‌ها را حذف کنم؟

خیر. حذف کورکورانه همه ریویژن‌ها، سه پیامد پنهان دارد: از دست دادن تاریخچه تغییرات، یتیم شدن داده‌های meta، و مشکل در سایت‌های چندنویسنده. روش درست: ابتدا با تنظیم WP_POST_REVISIONS در فایل wp-config.php محدودیت بگذارید، سپس فقط ریویژن‌های قدیمی‌تر از یک بازه مشخص را پاک کنید. برای وردپرس نسخه ۶ و بالاتر، تعداد پنج ریویژن معمولاً تعادل خوبی بین دسترسی به تاریخچه و صرفه‌جویی در فضا است.

گزینه‌های یتیم در wp_options را چطور شناسایی کنم؟

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

بهینه‌سازی دیتابیس چقدر روی سرعت سایت اثر دارد؟

پاسخ دقیق به وضعیت سایت شما بستگی دارد. در سایت‌هایی که دیتابیس واقعاً گلوگاه است، بهینه‌سازی صحیح می‌تواند TTFB را ۲۰ تا ۵۰ درصد کاهش دهد. اما در سایت‌هایی که مشکل اصلی در قالب سنگین یا هاست ضعیف است، بهینه‌سازی دیتابیس اثر محدودی دارد. تشخیص درست گلوگاه واقعی، اولین قدم هر بهینه‌سازی مؤثر است.

بهینه‌سازی دیتابیس چقدر هزینه دارد؟

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

آن‌چه سال‌ها بعد روی دیتابیس شما می‌ماند

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

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

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

اگر تجربه‌ای از اشتباهات بهینه‌سازی دیتابیس در پروژه‌های واقعی دارید — به‌خصوص اگر تجربه‌ای با پیامدهای غیرمنتظره یک عملیات به‌نظر بی‌خطر داشته‌اید — در دیدگاه‌ها بنویسید. این تجربه‌های میدانی، برای خواننده بعدی که این مسیر را می‌رود، از هر مستند رسمی ارزشمندترند. 🗄️