ضبط الأداء MySQL

هذه الصفحة هي وثائق PmaControl الأصلية. ويستخدم بنية فهرس عملية للعمل على تحسين MySQL، دون نسخ محتوى جهة خارجية أو الاعتماد على منتج خارجي.

الهدف

يتكون ضبط MySQL من تقليل زمن الوصول وتثبيت الإنتاجية وتجنب التشبع المتكرر. يجب أن يبدأ العمل من قياسات حقيقية وليس من قيم عامة منسوخة من خادم إلى آخر.

أمر العمل الموصى به

1. التقط الحمل الحقيقي: QPS، وزمن الوصول، والأخطاء، والاتصالات، وإدخال/إخراج القرص، والذاكرة، ووحدة المعالجة المركزية.
2. حدد الاستعلامات السائدة باستخدام performance_schema أو السجل البطيء أو أداة الملخص.
3. تحقق من المخطط: الفهارس المفقودة، والفهارس الزائدة، والأنواع واسعة جدًا، والجداول التي لا تحتوي على مفتاح أساسي.
4. اضبط InnoDB: تجمع المخزن المؤقت، وسجل الإعادة، والتدفق، وخيوط الإدخال/الإخراج، واستراتيجية المتانة.
5. قم بمراجعة حدود الخادم: الاتصالات والملفات المفتوحة وذاكرة التخزين المؤقت للجدول وأحجام الجدول المؤقتة.
6. اختبر على نافذة يمكن التحكم فيها، مع الرجوع إلى الحالة السابقة الموثقة.

أوامر مفيدة

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

للتذكر

الضبط الجيد MySQL يكون تدريجيًا. يصبح المتغير المعدل دون القياس قبل/بعد مصدرًا للدين التشغيلي.

إنشاء خط أساس قابل للمقارنة

سجّل إصدار الخادم بدقة، وموارد المضيف، وحجم البيانات، وإصدار التطبيق، وطبيعة الحركة وفترة المراقبة. افصل زمن استجابة العميل عن زمن تنفيذ SQL: قد تهيمن طوابير تجمع الاتصالات وزمن الشبكة ومعالجة التطبيق حتى لو كانت الاستعلامات سريعة. استخدم الحمل نفسه ومستوى التزامن نفسه قبل التغيير وبعده.

SELECT VERSION() AS server_version, @@version_comment AS distribution;
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
  'Innodb_buffer_pool_read_requests', 'Innodb_buffer_pool_reads',
  'Innodb_log_waits', 'Created_tmp_tables', 'Created_tmp_disk_tables'
);

خذ لقطتين خلال فترة تمثل الحمل الفعلي. Questions عدّاد تراكمي: معدل تعليمات العميل = ΔQuestions / الزمن بالثواني، وليس قيمة العدّاد نفسها. إعادة التشغيل أو تصفير العدّاد تُبطل الفترة. سجّل أزمنة p50 وp95 وp99 مع العمل المكتمل والأخطاء؛ فقد يخفي انخفاض المتوسط تدهور أبطأ الاستجابات.

تحديد الاستعلامات الأكثر استهلاكاً

SELECT SCHEMA_NAME, LEFT(DIGEST_TEXT, 140) AS digest,
       COUNT_STAR AS executions,
       ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds,
       ROUND(AVG_TIMER_WAIT / 1000000000, 3) AS average_ms,
       SUM_ROWS_EXAMINED, SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

يرتّب استعلام MySQL Performance Schema هذا زمن التنفيذ التراكمي، لا p95 لفترة حديثة. وحدات التوقيت هي البيكوثانية. تحقّق من تفعيل القياس وسجل التصفير؛ فالنتيجة الفارغة لا تثبت غياب الحمل. قد تكون الاستعلامات القصيرة المتكررة أعلى كلفة من استعلام بطيء واحد. قارن الصفوف المفحوصة بالصفوف المعادة، ثم استخدم EXPLAIN FORMAT=JSON بمعاملات ممثلة. ينفّذ EXPLAIN ANALYZE التعليمة فعلياً، لذلك استخدم بيئة مضبوطة وإصداراً يدعمه.

ربط الإجراء بمصدر الاختناق

التحقق من تغيير واحد في كل مرة

دوّن الفرضية والإعداد أو المخطط السابق والفائدة المتوقعة وشرط التراجع. هيّئ الذاكرة المخبأة بطريقة متسقة، وكرّر التجارب الممثلة واحتفظ بالنتائج الخام. قارن زمن الاستجابة ومعدل الإنجاز والأخطاء وCPU والذاكرة وI/O وتأخر النسخ معاً. ارفض تسريعاً يضر بصحة النتائج أو المتانة أو أحمال مهمة أخرى. أعد التحقق في الذروة وخلال دورة عمل كاملة قبل اعتماد التغيير.

متابعة التشخيص

• تحدد فحوصات السلامة التوافر والسعة.
• تشرح فحوصات المخطط ومعاملات الأداء التدخلات المحددة.

المراجع الرسمية

• MySQL Performance Schema
• MySQL EXPLAIN