Share via

ضبط الأداء والحفاظ على قواعد البيانات في قاعدة بيانات Azure ل MySQL - الخادم المرن باستخدام sys_schema

  • مقالة

ينطبق على:قاعدة بيانات Azure لـ MySQL - خادم فردي قاعدة بيانات Azure لـ MySQL - خادم مرن

هام

قاعدة بيانات Azure لخادم MySQL الفردي على مسار الإيقاف. نوصي بشدة بالترقية إلى قاعدة بيانات Azure لخادم MySQL المرن. لمزيد من المعلومات حول الترحيل إلى خادم Azure Database for MySQL المرن، راجع ما الذي يحدث لقاعدة بيانات Azure لخادم MySQL الفردي؟

يوفر MySQL performance_schema، المتاح أولاً في MySQL 5.5، تقرير عن حالة النظام للعديد من الموارد الحيوية للخادم مثل تخصيص الذاكرة والبرامج المخزنة وتأمين بيانات التعريف وما إلى ذلك. مع ذلك، يحتوي performance_schema على أكثر من 80 جدولاً، وغالباً ما يتطلب الحصول على المعلومات الضرورية ربط الجداول داخل performance_schema والجداول من information_schema. بناء على كل من performance_schema information_schema، يوفر sys_schema مجموعة قوية من طرق العرض سهلة الاستخدام في قاعدة بيانات للقراءة فقط ويتم تمكينه بالكامل في قاعدة بيانات Azure لإصدار الخادم المرن 5.7 ل MySQL.

Views of sys_schema.

توجد 52 طريقة عرض في sys_schema، ولكل طريقة عرض واحدة من البادئات التالية:

  • Host_summary أو IO: زمن الانتقال للإدخال/الإخراج.
  • InnoDB: حالة المخزن المؤقت InnoDB والتأمين.
  • Memory: استخدام الذاكرة من قبل المضيف والمستخدمين.
  • Schema: المعلومات المتعلقة بالمخطط، مثل الزيادة التلقائية، والفهارس، وما إلى ذلك.
  • Schema: معلومات حول بيانات SQL؛ يمكن أن يكون البيان الذي أدى إلى فحص الجداول بالكامل، أو وقت الاستعلام الطويل.
  • User: الموارد المستهلكة والمُجمّعة من قبل المستخدمين. ومن أمثلة ذلك اتصالات عمليات الإدخال/الإخراج للملفات والاتصالات والذاكرة.
  • Wait: أحداث الانتظار المجمّعة من قبل المضيف أو المستخدم.

دعونا نتناول بعض أنماط الاستخدام الشائعة لـ sys_schema. في البداية، سنقوم بتجميع أنماط الاستخدام في فئتين: Performance tuning وDatabase maintenance.

ضبط الأداء

sys.user_summary_by_file_io

الإدخال/الإخراج هي العملية الأكثر تكلفة في قاعدة البيانات. يمكننا معرفة متوسط زمن انتقال الإدخال/الإخراج عن طريق الاستعلام عن طريقة العرض sys.user_summary_by_file_io. بالتخزين الافتراضي المقدر بـ 125 غيغابايت، زمن انتقال الإدخال/الإخراج لدي حوالي 15 ثانية.

IO latency: 125 GB.

نظرا لأن خادم Azure Database for MySQL المرن يقوم بتحجيم IO فيما يتعلق بالتخزين، بعد زيادة التخزين المقدم إلى 1 ТБ، يقل زمن انتقال IO الخاص بي إلى 571 مللي ثانية.

IO latency: 1TB.

sys.schema_tables_with_full_table_scans

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

Full table scans.

sys.user_summary_by_statement_type

لاستكشاف مشكلات أداء قاعدة البيانات وإصلاحها، قد يكون من المفيد تحديد الأحداث التي تقع داخل قاعدة بياناتك، وقد يكون استخدام طريقة العرض sys.user_summary_by_statement_typeكافياً.

Summary by statement.

في هذا المثال، قضى خادم Azure Database for MySQL المرن 53 دقيقة في مسح سجل الاستعلام البطيء 44579 مرة. هذا يعني وقت طويل والعديد من عمليات الإدخال/الإخراج. يمكنك تقليل هذا النشاط إما عن طريق تعطيل سجل الاستعلام البطيء أو تقليل تكرار تسجيل الدخول البطيء إلى مدخل Azure للاستعلام.

صيانة قاعدة البيانات

sys.innodb_buffer_stats_by_table

[مهم!]

يمكن أن يؤثر الاستعلام عن طريقة العرض هذه على الأداء. من المستحسن تنفيذ استكشاف الأخطاء وإصلاحها أثناء ساعات العمل بعيداً عن ذروة الاستخدام.

توجد ذاكرة التخزين المؤقت InnoDB في الذاكرة وهو آلية التخزين المؤقت الرئيسي بين نظام إدارة قواعد البيانات (DBMS) والتخزين. يرتبط حجم ذاكرة التخزين المؤقت InnoDB بمستوى الأداء ولا يمكن تغيير ذلك ما لم يتم اختيار SKU منتج مختلف. كما هو الحال مع الذاكرة في نظام التشغيل لديك، يتم تبديل الصفحات القديمة لإفساح المجال للبيانات الحديثة. لتحديد الجداول التي تستخدم معظم ذاكرة التخزين المؤقت InnoDB، يمكنك الاستعلام عن طريقة العرض sys.innodb_buffer_stats_by_table.

InnoDB buffer status.

في الرسم البياني بالأعلى، يتضح لنا أنه بخلاف جداول النظام وطرق العرض، يشغّل كل جدول في قاعدة بيانات mysqldatabase033، التي تستضيف أحد مواقع WordPress‏ 16 كيلوبايت أو صفحة واحدة من البيانات في الذاكرة.

sys.schema_redundant_indexes Sys.schema_unused_indexes

الفهارس أدوات رائعة لتحسين أداء القراءة، ولكنها تُكبد تكاليف إضافية للإدراج والتخزين. يوفر كل من Sys.schema_unused_indexes وsys.schema_redundant_indexes تفاصيل حول الفهارس غير المستخدمة أو المُكررة.

Unused indexes.

Redundant indexes.

الخاتمة

باختصار، sys_schema أداة رائعة لضبط الأداء وصيانة قاعدة البيانات. تأكد من الاستفادة من هذه الميزة في مثيل خادم Azure Database for MySQL المرن.

الخطوات التالية

  • للعثور على إجابات النظير لأسئلة الأكثر شيوعاً أو نشر سؤال/إجابة جديدة، تفضل بزيارة Stack Overflow.