مخطط الأداء ولوحات المعلومات PmaControl: تتبع الاستعلامات البطيئة

مخطط الأداء: منجم الذهب غير المستغل

تم تمكين performance_schema بشكل افتراضي في MariaDB / MySQL لسنوات. ومع ذلك، فإن غالبية مسؤولي قواعد البيانات لا يستخدمونها بشكل يومي. والسبب بسيط: من الصعب قراءة البيانات الأولية. عشرات الجداول، وملايين الصفوف، والعدادات التراكمية - بدون أداة التجميع، يصبح الأمر ضجيجًا.

PmaControl يحول هذا الضجيج إلى إشارة. فهو يجمع البيانات من performance_schema عبر المكنسة الكهربائية، ويجمعها عبر المستمع (الملخص::تكامل)، ويقدمها في لوحات معلومات قابلة للاستخدام. تشرح هذه المقالة المسار الكامل، من المصدر إلى لوحة المعلومات.

تحقق من تمكين مخطط الأداء

MariaDB

SHOW GLOBAL VARIABLES LIKE 'performance_schema';
+--------------------+-------+
| Variable_name      | Value |
+--------------------+-------+
| performance_schema | ON    |
+--------------------+-------+

إذا كان OFF، أضف ملف التكوين:

[mysqld]
performance_schema = ON

يلزم إعادة التشغيل — هذا المتغير ليس ديناميكيًا.

MySQL

نفس الشيء على MySQL. المتغير للقراءة فقط ويتطلب إعادة التشغيل:

[mysqld]
performance_schema = ON

التأثير على الأداء

السؤال الكلاسيكي: "هل يؤدي مخطط الأداء إلى إبطاء الخادم الخاص بي؟" الجواب في عام 2026 هو لا، بشكل قابل للقياس. تبلغ التكلفة العامة حوالي 1-3% على أعباء العمل النموذجية. الفائدة في الرؤية أكثر من تعويض هذه التكلفة.

الاستثناء الوحيد: الخوادم ذات أعباء العمل الشديدة (> 100000 طلب في الثانية) حيث يتم احتساب كل نسبة مئوية. في هذه الحالة، قم بتعطيل الأدوات غير الضرورية بدلاً من مخطط الأداء بأكمله.

المصدر: events_statements_summary_by_digest

الجدول الرئيسي الذي يستخدمه PmaControl هو:

SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10\G

يحتوي هذا الجدول على ملخص حسب البصمة (بصمة طبيعية) لكل استعلام تم تنفيذه. فيما يلي الأعمدة الأكثر فائدة:

بصمة الإصبع هي حجر الأساس: فهي تعمل على تطبيع SELECT * FROM users WHERE id = 42 وSELECT * FROM users WHERE id = 1337 في بصمة واحدة SELECT * FROM users WHERE id = ?. يتيح ذلك تجميع الإحصائيات بشكل مستقل عن قيم المعلمات.

خط الأنابيب PmaControl

الخطوة 1: التجميع بواسطة المكنسة الكهربائية

يقوم الفراغ بتنفيذ الاستعلام التالي بشكل دوري على كل خادم خاضع للإشراف:

SELECT
    DIGEST,
    DIGEST_TEXT,
    COUNT_STAR,
    SUM_TIMER_WAIT,
    AVG_TIMER_WAIT,
    SUM_ROWS_EXAMINED,
    SUM_ROWS_SENT,
    SUM_NO_INDEX_USED,
    SUM_NO_GOOD_INDEX_USED,
    FIRST_SEEN,
    LAST_SEEN
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 500;
`

LIMIT 500` مقصود: PmaControl يركز على أغلى 500 استعلام في الوقت التراكمي. الاستعلامات السريعة والنادرة ليست مثيرة للاهتمام للتحسين.

يتم تخزين النتائج في ts_value_general_json بطابع زمني.

الخطوة 2: المعالجة من قبل المستمع

عندما يكتشف المستمع بيانات ملخصة جديدة، فإنه يقوم بتشغيل Digest::integrate(). هذه الوظيفة:

1. حساب الدلتا: نظرًا لأن performance_schema يوفر عدادات تراكمية (منذ آخر TRUNCATE أو إعادة التشغيل)، فإن Digest::integrate يحسب الفرق بين مجموعتين للحصول على مقاييس الفترة.

2. تطبيع الأوقات: يتم تحويل البيكو ثانية إلى ميلي ثانية للعرض.

3. حساب النسب المئوية: يتم تقدير P95 (المئين 95) من وقت التنفيذ من التوزيعات.

4. مخزن في ts_mysql_digest_stat: الجدول المخصص لملخص الإحصائيات، مقسم حسب اليوم واستخدام محرك RocksDB للضغط.

Aspirateur
  → SELECT FROM performance_schema (every minute)
  → INSERT INTO ts_value_general_json

Listener
  → Detect new data (ts_max_date changed)
  → Digest::integrate()
     → Delta calculation (current - previous)
     → Normalize to milliseconds
     → Estimate P95
     → INSERT INTO ts_mysql_digest_stat

جدول ts_mysql_digest_stat

هذا هو التخزين طويل المدى لإحصائيات الملخص:

CREATE TABLE ts_mysql_digest_stat (
    id BIGINT UNSIGNED AUTO_INCREMENT,
    server_id INT UNSIGNED,
    digest VARCHAR(64),
    digest_text TEXT,
    period_start DATETIME,
    period_end DATETIME,
    exec_count BIGINT UNSIGNED,
    total_time_ms DECIMAL(20,3),
    avg_time_ms DECIMAL(15,3),
    p95_time_ms DECIMAL(15,3),
    rows_examined BIGINT UNSIGNED,
    rows_sent BIGINT UNSIGNED,
    no_index_used BIGINT UNSIGNED,
    PRIMARY KEY (id),
    KEY idx_server_digest (server_id, digest, period_start)
) ENGINE=ROCKSDB
PARTITION BY RANGE (TO_DAYS(period_start)) (
    PARTITION p20260413 VALUES LESS THAN (TO_DAYS('2026-04-14')),
    PARTITION p20260414 VALUES LESS THAN (TO_DAYS('2026-04-15')),
    ...
);

يسمح التقسيم حسب اليوم بما يلي:

• تنظيف سريع: ALTER TABLE ts_mysql_digest_stat DROP PARTITION p20260401;
• استعلامات سريعة على نطاق زمني
• التحكم الدقيق في الإحتفاظ

لوحات المعلومات

عرض أهم الاستعلامات

تعرض لوحة المعلومات الرئيسية الطلبات الأكثر تكلفة، مرتبة حسب الوقت التراكمي:

Rang  Fingerprint                              Exec/h    Avg(ms)   P95(ms)  Rows Exam
───── ──────────────────────────────────────── ────────  ────────  ──────── ─────────
  1   SELECT * FROM orders WHERE customer_id    12,430     45.2     234.5   1,245,000
      = ? AND status = ?
  2   UPDATE inventory SET stock = stock - ?     8,200     12.3      89.1     820,000
      WHERE product_id = ?
  3   SELECT o.*, c.name FROM orders o JOIN      3,150     78.9     445.2   3,150,000
      customers c ON o.customer_id = c.id
  4   INSERT INTO audit_log (...)                45,600      1.2       5.3          0
  5   SELECT COUNT(*) FROM sessions WHERE         980    234.5     890.1  98,000,000
      last_active < ?

كل سطر قابل للنقر للوصول إلى التفاصيل.

عرض تفصيلي لبصمة الإصبع

من خلال النقر على بصمة الإصبع، يعرض PmaControl:

• النص الكامل للاستعلام الموحد
• التاريخ: تطور متوسط وقت التنفيذ وP95 خلال آخر 30 يومًا
• النسبة صفوف_فحصها / صفوف_إرسالها — تشير النسبة العالية (>100:1) إلى مسح جدول أو فهرس مفقود
• العلامة no_index_used — عدد عمليات التنفيذ التي لم تستخدم أي فهرس

تحديد الفهارس المفقودة

تعتبر نسبة الصفوف_المفحوصة/الصفوف_المرسلة أقوى مؤشر. لنأخذ مثالا:

Fingerprint: SELECT * FROM orders WHERE customer_id = ?
Rows examined: 1,245,000 (total)
Rows sent: 12,430 (total)
Ratio: 100:1

تعني هذه النسبة 100:1 أن MariaDB / MySQL يفحص 100 صف لإرجاع 1. هذه هي العلامة الكلاسيكية لمسح جدول كامل أو فهرس غير فعال.

الإجراء: التحقق من وجود فهرس على customer_id:

SHOW INDEX FROM orders WHERE Column_name = 'customer_id';

إذا كان الفهرس غير موجود:

ALTER TABLE orders ADD INDEX idx_customer_id (customer_id);

علامة SUM_NO_INDEX_USED

يعرض PmaControl الاستعلامات حيث يكون SUM_NO_INDEX_USED مرتفعًا باللون الأحمر. يتم تعيين هذه العلامة عندما يقوم MariaDB / MySQL بإجراء فحص كامل للجدول - وغالبًا ما تكون هذه مشكلة الأداء الأولى.

شرح من PmaControl

بالنسبة للاستعلامات التي تم تحديدها على أنها إشكالية، يمكن لـ PmaControl تنفيذ EXPLAIN مباشرةً:

EXPLAIN SELECT * FROM orders WHERE customer_id = 42 AND status = 'pending';

يتم عرض النتيجة مع رمز اللون:

• الأخضر: type = ref أو type = eq_ref — استخدام الفهرس، جيد
• العنبر: type = range — مسح النطاق، مقبول
• الأحمر: type = ALL — مسح الجدول بالكامل، ليتم تصحيحه

التكامل مع وكيل مارينا+

Marina+ هو وكيل التحسين التلقائي لـ PmaControl. يقوم بتحليل ملخص البيانات ويقدم الاقتراحات:

1. الفهارس المفقودة: يكتشف الاستعلامات التي تحتوي على نسبة عالية من الصفوف_المفحوصة/الصفوف_المرسلة ويقترح فهارسًا لإنشائها
2. الاستعلامات المراد إعادة كتابتها: تحدد الأنماط غير الفعالة (SELECT *، الاستعلامات الفرعية المرتبطة، ORDER BY في عمود غير مفهرس)
3. التكوين: يضبط معلمات الخادم بناءً على أنماط الطلب (sort_buffer_size، join_buffer_size، وما إلى ذلك)

لا تقوم خدمة Marina+ بتغيير أي شيء تلقائيًا - فهي تنشئ توصيات يتحقق منها DBA ويطبقها.

المقارنة مع PMM (Percona المراقبة والإدارة)

يستغل كل من PMM وPmaControl نفس مصدر البيانات (performance_schema)، ولكن بطرق مختلفة:

الفرق الرئيسي: يجمع PMM بين مخطط الأداء والسجل البطيء للحصول على نسب مئوية أكثر دقة. يعتمد PmaControl فقط على مخطط الأداء، وهو أخف وزنًا ولكنه أقل تفصيلاً.

ميزة PmaControl: التكامل مع بقية النظام البيئي (النسخ المتماثل، الهيكل، التنبيهات، الإجراءات). يعد PMM أفضل لتحليل الاستعلام النقي، PmaControl أفضل لعرض البنية التحتية الشاملة.

حالة عملية: البحث عن استعلام بطيء وتصحيحه

السيناريو: تعرض لوحة المعلومات PmaControl طلبًا يستهلك 40% من إجمالي وقت الخادم.

الخطوة 1: تحديد

في لوحة معلومات أهم الاستعلامات:

#1  SELECT u.*, p.* FROM users u
    JOIN purchases p ON u.id = p.user_id
    WHERE p.created_at > ? AND u.country = ?

    Exec/h: 5,200   Avg: 234ms   P95: 1,200ms   Rows exam: 45M

الخطوة الثانية: التحليل

تعتبر نسبة الصفوف التي تم فحصها / الصفوف التي تم إرسالها كارثية: تم فحص 45 مليون صف للحصول على 5200 نتيجة تقريبًا في الساعة.

اشرح من PmaControl:

+----+------+----------+------+------+------+----------+
| id | type | table    | key  | rows | filt | Extra    |
+----+------+----------+------+------+------+----------+
|  1 | ALL  | users    | NULL | 1.2M | 10%  | where    |
|  1 | ref  | purchases| idx1 | 15   | 33%  | where    |
+----+------+----------+------+------+------+----------+

المشكلة: يتم فحص users في الجدول الكامل (type = ALL). لا يوجد فهرس على country.

الخطوة 3: الإصلاح

ALTER TABLE users ADD INDEX idx_country (country);

الخطوة 4: التحقق

بعد إضافة الفهرس، تظهر لوحة المعلومات PmaControl التحسن خلال ساعة:

#1  SELECT u.*, p.* FROM users u
    JOIN purchases p ON u.id = p.user_id
    WHERE p.created_at > ? AND u.country = ?

    Exec/h: 5,200   Avg: 12ms   P95: 45ms   Rows exam: 78K

ارتفع متوسط ​​الوقت من 234 مللي ثانية إلى 12 مللي ثانية (x19)، وتم فحص الخطوط من 45 ميجا إلى 78 كيلو (x577).

أفضل الممارسات

1. لا تقم باقتطاع مخطط الأداء يدويًا

PmaControl يحسب الدلتا بين مجموعتين. إذا قمت بإجراء TRUNCATE TABLE performance_schema.events_statements_summary_by_digest، سيتم إعادة تشغيل العدادات من الصفر وستكون الدلتا الأولى غير صحيحة. دع PmaControl يتعامل مع الأمر.

2. قم بزيادة حجم ملخصات مخطط الأداء إذا لزم الأمر

افتراضيًا، يقوم MariaDB / MySQL بتخزين بصمات الأصابع N الأولى. إذا كان تطبيقك يحتوي على طلبات أكثر تميزًا عن الحد الأقصى، فسيتم استبعاد الطلبات الأقل تكرارًا:

[mysqld]
performance_schema_digests_size = 10000  ; défaut ~5000

3. ارتبط بسجل الاستعلام البطيء

PmaControl عبر مخطط الأداء يعطي "ماذا" (أي الاستعلامات بطيئة). يوفر سجل الاستعلام البطيء "متى" (في أي لحظة بالضبط). وهما متكاملان.

4. مراقبة نسبة الصفوف التي تم فحصها / الصفوف المرسلة

هذا هو المؤشر الأكثر قابلية للتنفيذ. دائمًا ما تكون النسبة > 100:1 مؤشرًا مفقودًا. النسبة > 1000:1 مشكلة ملحة.

5. استخدم P95، وليس متوسطًا

المتوسط يخفي القيم المتطرفة. طلب بمتوسط ​​10 مللي ثانية ولكن P95 يبلغ 500 مللي ثانية به مشكلة متقطعة (تنافس القفل، ذاكرة التخزين المؤقت الباردة، خطة التنفيذ غير المستقرة). يكشف P95 عن هذه المشاكل.

الخلاصة

يعد Performance_schema أفضل مصدر بيانات لتحسين استعلام MariaDB / MySQL. PmaControl يقوم بأتمتة جمع هذه البيانات وتجميعها وعرضها عبر خط أنابيب الفراغ → Digest::integrate → ts_mysql_digest_stat → لوحة المعلومات.

النتيجة: رؤية مستمرة لأغلى الاستعلامات والفهارس المفقودة واتجاهات الأداء بمرور الوقت. وبدمجه مع Marina+‎ للاقتراحات التلقائية، فإنه يمثل سير عمل كامل لتحسين الأداء - بدءًا من الاكتشاف وحتى المعالجة.