این صفحهٔ ستون خوشهٔ «دیتابیس و پرفورمنس» است. سؤال را همه می‌پرسند چون پنل هاست، هر دو را در یک فهرست می‌گذارد و هیچ توضیحی نمی‌دهد: «MySQL 8 یا MariaDB 10؟»
جواب کوتاه و صادق: برای وردپرس، در ۹۵٪Siteها، این انتخاب تفاوت محسوسی در سرعت ایجاد نمی‌کند و اهمیتش جای دیگری است — در نسخه، در کولیشن، و در کوئری‌هایی که افزونه‌ها می‌فرستند. این مقاله همان سه را باز می‌کند و در آخر می‌گوید مهاجرت بین دو موتور را کی باید انجام داد.
اول بفهم الان روی چه چیزی هستی
نسخه‌ای که در پنل نوشته‌شده، ممکن است نسخهٔ همان اکانت تو نباشد. روی سرورهای اشتراکی، هر حساب می‌تواند پیکربندی خودش را داشته باشد. مطمئن‌ترین راه، پرسیدن از خود موتور است:
SELECT VERSION();
SELECT @@version_comment;روی خط فرمان، با همان باینری که اکانتت استفاده می‌کند:
php -r 'require "wp-load.php"; global $wpdb; echo $wpdb->db_server_info()."\n".$wpdb->db_version()."\n";'چرا این اولویت دارد؟ چون پاسخ بیشتر سؤال‌های بعدی، به همین عدد بستگی دارد: آیا ایندکس‌سازی معین پشتیبانی می‌شود، آیا رفتار NULL در یکتا بودن فرق می‌کند، و آیا کولیشن‌های تازهٔ فارسی در دسترس‌اند یا نه.
تفاوت‌هایی که کاربر واقعاً حس می‌کند
تاریخچه را کنار می‌گذارم و به چیزی می‌رسم که در پروژه دیده می‌شود:
رفتار کوئری در نسخه‌های تازه. هر دو موتور در نسخه‌های جدید، به‌هم نزدیک‌تر شده‌اند تا نسخه‌های قدیمیِ خودشان. یعنی مقایسهٔ «MySQL قدیمی» با «MariaDB تازه» نتیجه را وارونه نشان می‌دهد. اگر جایی خواندی یکی قطعاً سریع‌تر است، ببین کدام نسخه مقایسه شده.
برنامه‌ریز کوئری. در کوئری‌های پیچیدهٔ فروشگاه‌ها — چند JOIN با فیلتر متا — تفاوت برنامه‌ریز میان دو موتور، چند صد میلی‌ثانیه جابه‌جا می‌کند. ولی همین تفاوت را با یک ایندکس درست می‌شود گرفت؛ پس اول آن.
ابزارها. بعضی ابزارهای تشخیص و بعضی دستورات مدیریتی روی یکی رفتار بهتری دارند. اگر به phpMyAdmin وابسته‌ای، تفاوت نسخهٔ موتور روی گزینه‌های این ابزار هم اثر می‌گذارد.
و نکته‌ای که کمتر گفته می‌شود: در هاست اشتراکی، بیشترِ زمان اجرای کوئری با ساختار دادهٔ بد می‌رود، نه با موتور. جدول‌های متورم، ایندکس غایب و کوئری در حلقه، روی هر دو موتور کندند.
کولیشن و متن فارسی؛ همین‌جا است که سایت می‌شکند
دو مسئلهٔ عملی:
یک: charset. اگر دیتابیس با charset قدیمی ساخته شده باشد، رشته‌های چهاربایتی (شامل بعضی نشانه‌ها و ایموجی در کامنت و آدرس) نصفه ذخیره یا رد می‌شوند. تشخیص:
SHOW CREATE DATABASE;
SELECT DEFAULT_CHARACTER_SET_NAME, DEFAULT_COLLATION_NAME
FROM information_schema.SCHEMATA;دو: کولیشن فارسی. هر دو موتور کولیشن ویژهٔ فارسی دارند. تفاوت‌اش در مرتب‌سازی و در برابر‌گرفتن بعضی نویسه‌هاست — مثلاً «ی» و «ک» یا «ک» و «گ» در جستجو و در ORDER BY. اگر افزونهٔ جستجوی سایت یا مرتب‌سازی محصول، نتیجهٔ عجیب می‌دهد، احتمال دارد مسئله اینجا باشد نه در کد.
تلهٔ رایج: تبدیل وسط کار. ALTER TABLE ... CONVERT TO روی جدول بزرگ، جدول را قفل می‌کند و سایت در همان زمان بی‌پاسخ می‌شود. اگر جدول بزرگ است، این کار را در بازهٔ کم‌ترافیک و با نسخهٔ پشتیبان انجام بده، یا جدول را در ساختار تازه بساز و داده را منتقل کن.
مهاجرت بین دو موتور؛ کی منطقی است و کی نه
سه موقعیت که مهاجرت در آن‌ها ارزش دارد:
۱. نسخهٔ فعلی‌ات پشتیبانی امنیتیش تمام شده و میزبان ارتقا نمی‌دهد. ۲. به قابلیتی نیاز داری که فقط در آن موتور هست و بدون آن، مجبوری در PHP همان کار را بکنی. ۳. میزبان، سرور تازه‌ای با یکی از دو موتور داده و انتخابی نداری.
و یک موقعیت که ارزش ندارد: «فلان بنچمارک گفته سریع‌تر است». بنچمارک خام با Sysbench چیزی دربارهٔ کوئری‌های وردپرس تو نمی‌گوید. اگر کنجکاوی، همین مقایسه را روی سایت خودت بکن — روی استیج، با همان داده:
SELECT SQL_NO_CACHE ... ;کوئری سنگین فروشگاه را سه بار روی هر موتور اجرا کن و میانه را مقایسه کن. اختلاف زیر چند درصد، ارزش ریسک مهاجرت را ندارد.
اگر مهاجرت کردی، این چهار چیز را چک کن
یک: رفتار NULL در ستون یکتا. در بعضی نسخه‌ها چند ردیف NULL در ستون UNIQUE پذیرفته می‌شود و در بعضی نه. افزونه‌هایی که با «یکتا» کار می‌کنند ممکن است خطای کلید تکراری بدهند.
دو: طول پیشوند ایندکس. در utf8mb4، هر نویسه تا چهار بایت است؛ ایندکس روی ستون متنی بلند، ممکن است از حد مجاز رد شود. علامتش خطای Specified key was too long.
سه: کوئری‌های دست‌نویس افزونه‌ها. افزونه‌ای که کوئری خام با سینتکس خاص نوشته، ممکن است روی موتور دیگر خطا بدهد. بعد از مهاجرت، مسیرهای پول‌ساز را دستی برو: ورود، سبد، تسویه، فرم تماس، جستجو.
چهار: پیکربندی. متغیرهای مهم مثل اندازهٔ استخر ایننادبی و سقف اتصالات، روی هر سرور دستی تنظیم می‌شوند. مهاجرت موتور، اینها را با خودشان منتقل نمی‌کند. مقایسهٔ قبل و بعد از مهاجرت بدون نگاه به این متغیرها، نتیجهٔ گمراه‌کننده می‌دهد.
برای وردپرس چه تنظیمی واقعاً اثر دارد
سه تنظیم که در سایت متوسط اثرشان محسوس‌تر از انتخاب موتور است:
اندازهٔ استخر. اگر کل دیتابیس در حافظه جا می‌شود، خواندن از دیسک به‌شدت کم می‌شود. روی هاست اشتراکی، این عدد را تو تعیین نمی‌کنی؛ ولی باید بدانی هست تا وقتی پشتیبانی می‌گویی «دیتابیس کند است»، عدد داشته باشی.
بازگشت کوئری. کش کوئری در نسخه‌های تازه کنار گذاشته شده. اگر افزونه‌ای هنوز روی آن حساب کرده، بی‌اثر است؛ و کش شیء در PHP جای درست‌تر این کار است.
اتصال ماندگار و سقف اتصال. در LiteSpeed، workerهای PHP هر کدام اتصال می‌گیرند. سقف اتصال کم باشد، درخواست‌ها پشت صف می‌مانند و عدد TTFB بالا می‌رود بدون اینکه کوئری سنگین داشته باشی.
چه وقت نگران شویم؛ نشانهٔ واقعی
سه نشانه که مشکل از دیتابیس است، نه از وب‌سرور یا قالب:
۱. صفحه‌های کش‌شده سریع‌اند و صفحه‌های کش‌رد‌شده کند؛ چون دیتابیس در مسیر دوم درگیر است. ۲. در ساعت شلوغی کندی محسوس است و در ساعت خلوت نه. ۳. شمار کوئری در یک صفحه با افزایش تعداد آیتم‌ها رشد می‌کند، نه ثابت می‌ماند؛ این الگوی «کوئری در حلقه» است و با موتور ربطی ندارد.
در هر سه حالت، اول مقالهٔ «پیدا کردن کوئری کند» و بعد «تورم جدول postmeta» را بخوان. انتخاب موتور، آخرین متغیری است که باید دست بزنی.
نسخه یا موتور؟ اولویت را اشتباه نگیر
بیشترین انرژی‌ای که در پروژه‌ها در این موضوع هدر می‌رود، این است: صاحب سایت می‌پرسد «MySQL بهتر است یا MariaDB»، در حالی که سؤال درست این است «نسخه‌ای که روش اجرا می‌کنم، هنوز امن و پشتیبانی می‌شود؟»
چرا این اولویت؟ چون آسیب‌های واقعی دیتابیس در سطح نسخه اعلام می‌شوند، نه در سطح نام موتور. یک نسخهٔ قدیمی از هر دو موتور، هم ضعف امنیتی دارد هم افت کارایی؛ و یک نسخهٔ تازه از هر دو، برای وردپرس کافی است. نشانهٔ تشخیص خیلی ساده است: اگر شمارهٔ نسخه‌ات به سال‌های قبل می‌رسد، مسئله همان نسخه است، نه انتخاب برند.
سه نشانهٔ عملی که نسخهٔ تو قدیمی است:
۱. افزونه‌های تازه در صفحهٔ اطلاعات پرسیدنی، هشدار «نسخهٔ سازگار نیست» نشان می‌دهند. ۲. بعضی کولیشن‌های فارسی در فهرست SHOW COLLATION نیستند. ۳. میزبان، برای اکانت تو گزینهٔ ارتقا باز نمی‌گذارد یا نسخه را در جای دیگری قفل کرده است.
در هر سه حالت، گفت‌وگو با میزبان را شروع کن؛ نه مهاجرت را.
یک آزمایش کوتاه که جواب را محلی می‌کند
اگر می‌خواهی بدون بحث کلی، تفاوت را روی سایت خودت ببینی، این آزمایش بیست دقیقه وقت می‌گیرد و نتیجه‌اش قابل‌دفاع است:
یک. روی استیج، همان دیتابیس را با همان داده بالا بیاور. دو. سه کوئری سنگین واقعی سایتت را انتخاب کن: فهرست محصول با فیلتر، جستجو، و کوئری صفحهٔ دسته‌بندی. سه. هر سه را سه بار اجرا کن و میانهٔ زمان را بنویس. چهار. روی موتور دیگر تکرار کن. پنج. خروجی EXPLAIN دو طرف را مقایسه کن، نه فقط زمان را.
چرا پنج مهم‌تر از سه و چهار است؟ چون تفاوت زمان ممکن است از گرم‌بودن کش باشد؛ ولی تفاوت در نقشهٔ اجرا — نوع پیمایش، نوع join، و شمار ردیف بررسی‌شده — نشان می‌دهد که موتور واقعاً کار دیگری انجام داده است یا نه. اگر نقشه‌ها یکی‌اند و زمان چند درصد فرق دارد، موضوع تمام شده و وقتت را برای موتور دیگری صرف نکن.
این را هم در نظر بگیر: روی هاست اشتراکی، دو سرور متفاوت با یک موتور، بیشتر از دو موتور روی یک سرور با هم فرق دارند. یعنی متغیر «سرور» از متغیر «موتور» بزرگ‌تر است. نتیجهٔ بنچمارک‌های مقایسه‌ای که از این تفکیک غافل‌اند، بی‌معناست.
چند رفتار که در مهاجرت باید بدانی
سه تفاوت رفتاری که در پروژه‌های واقعی به من برگشتند. هر سه، قبل از مهاجرت قابل‌بررسی‌اند:
یک: مرتب‌سازی و برابر‌گیری در کولیشن. کولیشن‌های فارسی، در برابر «ی» و «ی» یا «ک» و «ک» رفتار متفاوتی دارند. نتیجهٔ عملی: افزونه‌ای که جستجوی متنی انجام می‌دهد، روی یکی نتیجه می‌دهد و روی دیگری نه. پیش از مهاجرت، یک جستجوی واقعی با هر دو شکلِ یک حرف امتحان کن.
دو: مقادیر پیش‌فرض در ستون‌های متنی. بعضی نسخه‌ها مقدار پیش‌فرض رشته‌ای در ستون TEXT را نمی‌پذیرند. اگر افزونه‌ای جدول خودش را در زمان فعال‌سازی می‌سازد، ممکن است خطای ساخت جدول بدهد، آن هم بی‌صدا و فقط در لاگ.
سه: رفتار GROUP BY با ستون‌های غیردربرگیرنده. در بعضی پیکربندی‌ها این کوئری خطا می‌دهد و در بعضی با مقدار دل‌خواه جواب. افزونه‌های قدیمی روی حالت دوم حساب کرده‌اند؛ علامتش، گزارش‌های عددی است که دو بار اجرا، دو جواب متفاوت می‌دهند.
ویرایش بی‌خطر کولیشن: مسیر پیشنهادی
اگر به charset یا کولیشن درست رسیدی، این ترتیب، ریسک را پایین نگه می‌دارد:
۱. بکاپ کامل، و تست بازگردانی همان بکاپ روی محیط دیگر. بدون این، سراغ تغییر نرو. ۲. تغییر در سطح دیتابیس برای ساخته‌های جدید، نه tables پرجمعیت. ۳. تغییر جدول‌ها یکی‌یکی، با شروع از جدول‌های کوچک؛ جدول نوشته‌ها و postmeta را آخر نگه دار. ۴. بعد از هر جدول، سه مسیر را تست کن: ورود، جستجو، فهرست محصول. ۵. اگر جدولی بزرگ است، تغییر ساختار را در کپی انجام بده و بعد نام دو جدول را عوض کن؛ روشی که قفل طولانی نسازد.
علامت اینکه داری اشتباه می‌کنی: در میانهٔ کار، سایت پاسخ نمی‌دهد. اگر این شد، ادامه نده و برگردان. تغییر نیمه‌کارهٔ کولیشن، از خرابی کامل بدتر است، چون داده‌ات را در حالت نامشخص می‌گذارد.
چه چیزی را نمی‌شود با انتخاب موتور حل کرد
چهار مسئله‌ای که در همین خوشه مقالهٔ جدا دارند و با عوض‌کردن موتور بهتر نمی‌شوند:
کوئری در حلقه. افزونه‌ای برای هر آیتم منو، یک کوئری می‌زند. صد آیتم، صد کوئری. روی هر موتوری کند است.
جدول گزینه‌های متورم. داده‌های جا‌مانده از افزونه‌های حذف‌شده که در هر درخواست خوانده می‌شوند.
ایندکس غایب. فیلتر روی ستونی که ایندکس ندارد، کل جدول را می‌خواند.
نبود کش شیء. همان نتیجهٔ کوئری، ده بار در یک صفحه محاسبه می‌شود.
اولویت درست این است: کوئری‌ها را کم کن، ایندکس را درست کن، دادهٔ مرده را پاک کن، و بعد اگر هنوز کنجکاوی، موتور را مقایسه کن. در تجربهٔ من، سه حرکت اول تقریباً همیشه بیشتر از حرکت چهارم عدد جابه‌جا می‌کنند.
تصمیم عملی: چه چیزی را کجا بپرسی
جمع‌بندی این خوشه در سه پرسش روشن، که هر کدام جای درست پرسیدنش فرق می‌کند:
از میزبان بپرس: نسخهٔ موتور و PHP اکانت من چیست، سیاست پشتیبانی امنیتی تا کجاست، و آیا امکان انتخاب نسخه برای همین اکانت وجود دارد. سه جملهٔ کوتاه است و نصف تصمیم را مشخص می‌کند. اگر پاسخ مبهم بود، همان ابهام علامت خطر است.
از افزونه‌ات بپرس: آیا جدول اختصاصی می‌سازد و با چه کولیشنی؟ آیا کوئری خام می‌نویسد؟ آیا در حلقه کوئری می‌زند؟ این سه سؤال، مسئولیت کندی را از شانهٔ «موتور دیتابیس» برمی‌دارد و جای واقعی‌اش می‌گذارد. ابزار تشخیص ساده است: شمار کوئری را در یک صفحه ببین؛ اگر با تعداد آیتم‌ها بالا می‌رود، پاسخ روشن است.
از خودت بپرس: کدام عدد را می‌خواهی بهتر کنی؟ اگر TTFB در صفحه‌های کش‌رد‌شده است، دیتابیس و PHP مظنون‌اند. اگر زمان کل صفحه با حجم دانلود بالا می‌رود، دیتابیس ربطی ندارد و باید سراغ تصویر و اسکریپت بروی. بدون این تفکیک، هر تغییری — از جمله عوض‌کردن موتور — فقط یک آزمون پرهزینه است.
یک تجربهٔ بی‌ربط‌نما که در این مسیر زیاد تکرار می‌شود: کندی که «مسئلهٔ دیتابیس» به نظر می‌رسد، گاهی از کران وردپرس می‌آید؛ چون اولین بازدیدکنندهٔ بعد از هر بازهٔ کران، بار کار زمان‌بندی‌شده را هم روی دوش می‌کشد و کوئری‌هایش در همان درخواست اجرا می‌شود. اگر کندی نوسانی است و با ساعت کران می‌خواند، قبل از هر تصمیم دیتابیس، کران را به مسیر واقعی منتقل کن.
و یادآوری که در انتخاب موتور به کار می‌آید: دادهٔ مقایسه‌ای که از سایت خودت نگیری، فقط ادعاست. روی استیج، با همان داده، همان سه کوئری را اندازه بگیر و نقشهٔ اجرا را مقایسه کن؛ همان چیزی که در بالا گفتم. بقیهٔ خوشه، هر کدام یکی از این اندازه‌گیری‌ها را چطور انجام دهند نشان می‌دهند.
جمع‌بندی
برای وردپرس روی سی‌پنل، MariaDB و MySQL هر دو درست‌اند؛ انتخاب بین این دو، معمولاً تصمیم میزبان است نه تو. کاری که واقعاً نتیجه می‌دهد این است: نسخهٔ تازه و پشتیبانی‌شده داشته باشی، charset و کولیشن را برای متن فارسی درست کنی، جدول‌های متورم را تمیز کنی، و کوئری در حلقه را پیدا و حذف کنی.
اعضای این خوشه همین‌ها را باز می‌کنند: تشخیص کوئری کند، ثبت slow query log، ایندکس و کلید اصلی، جدول گزینه‌های متورم، تورم postmeta، کش شیء با Redis، و مسیر امن مهاجرت دیتابیس بین دو سرور.
مقالبی بخوانی
- تفاوت LiteSpeed با Nginx و Apache برای وردپرس؛ کدام وب‌سرور واقعیت را سریع می‌کند؟
- اعتبار موضوعی و لینک‌دهی خوشه‌ای؛ ساختار ستون و خوشه در عمل
- چرا سایت وردپرسی کند است؛ اندازه‌گیری به‌جای حدس
- محتوای انبوه یا Scaled Content Abuse؛ سیاستی که سایت‌های پُرمقاله را تنبیه می‌کند
- شصت روز اول یک پروژهٔ سئو؛ ترتیب واقعی کار
- امن‌سازی وردپرس روی هاست سی‌پنل؛ پانزده کاری که واقعاً مانع می‌شوند
امید بداق
من متخصص سئو که عاشق اینه به کسب‌وکارها کمک کنه تو گوگل دیده بشن!از وردپرس گرفته تا سئو، هرچیزی که برای رشد آنلاین نیاز داری میتونم کمکت کنم.