نصائح:
1. كيفية اكتشاف البيانات غير الفعالة؟
ضمن MySQL، من خلال تعيين --log-slow-queries=[اسم الملف] في معلمات بدء التشغيل، يمكنك تسجيل عبارات SQL التي يتجاوز وقت تنفيذها long_query_time (الافتراضي هو 10 ثوانٍ) في ملف السجل المحدد. يمكنك أيضًا تعديل وقت الاستعلام الطويل في ملف تكوين بدء التشغيل، مثل:
# ضبط وقت الاستعلام الطويل على 8 ثوانٍ
long_query_time=8
2. كيفية الاستعلام عن فهرس الجدول؟
يمكنك استخدام عبارة SHOW INDEX، مثل:
SHOW INDEX FROM [اسم الجدول]
3. كيفية الاستعلام عن استخدام الفهرس لعبارة معينة؟
يمكنك استخدام عبارة EXPLAIN لمعرفة استخدام الفهرس لعبارة SELECT معينة. إذا كانت عبارة UPDATE أو DELETE، فيجب تحويلها إلى عبارة SELECT أولاً.
4. كيفية تصدير محتويات محرك INNODB إلى ملف سجل الأخطاء؟
يمكننا استخدام الأمر SHOW INNODB STATUS لعرض الكثير من المعلومات المفيدة حول محرك INNODB، مثل العملية الحالية والمعاملات وأخطاء المفاتيح الخارجية والتوقف التام. مشاكل وإحصائيات أخرى. كيفية تمكين هذه المعلومات ليتم تسجيلها في ملف السجل؟ طالما قمت بإنشاء جدول innodb_monitor باستخدام العبارة التالية، فسوف يقوم MySQL بكتابة النظام إلى ملف سجل الأخطاء كل 15 ثانية:
CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB؛
إذا لم تعد بحاجة إلى التصدير إلى ملف سجل الأخطاء ما عليك سوى حذف هذا الجدول:
DROP TABLE innodb_monitor
5. كيفية حذف ملفات السجل الضخمة بانتظام؟
ما عليك سوى تعيين وقت انتهاء صلاحية السجل في ملف تكوين بدء التشغيل:
Experit_logs_days=10
ملاحظات:
1. ركز على الفهرس
يستخدم ما يلي الجدول TSK_TASK كمثال لتوضيح عملية تحسين عبارة SQL. يتم استخدام جدول TSK_TASK لحفظ مهام مراقبة النظام. الحقول والفهارس ذات الصلة هي كما يلي:
المعرف: المفتاح الأساسي؛
MON_TIME: وقت المراقبة؛
STATUS_ID: تم إنشاء علاقة المفتاح الخارجي باستخدام SYS_HIER_INFO.ID.
ملاحظة: سيقوم MySQL تلقائيًا بإنشاء فهارس للمفاتيح الخارجية أثناء عملية التحسين هذه، وقد وجد أن فهارس المفاتيح الخارجية التي تم إنشاؤها تلقائيًا ستتسبب في تداخل غير ضروري في كفاءة عبارات SQL.
أولاً، وجدنا في ملف السجل أن تنفيذ العبارة التالية كان بطيئاً نسبياً، أكثر من 10 ثوانٍ:
# Query_time: 18 Lock_time: 0 Rows_sent: 295 Rows_examined: 88143
حدد * from TSK_TASK WHERE STATUS_ID = 1064 and MON_TIME >= ' 2007-11 -22' and MON_TIME < '2007-11-23'؛
اتضح أنه من الضروري العثور على 295 سجلاً مطابقًا للشروط من بين 88143 سجلاً، وهو أمر بطيء بالطبع. استخدم عبارة EXPLAIN بسرعة للتحقق من استخدام الفهرس:
+----+------+----------+------+- ---------
|.select_type |. type |. key_len
| ----------+------+-----------
|. SIMPLE |. ref |
. +-------------+----------+------+----------
يمكن رؤية ذلك هناك يتوفر فهرسان: FK_task_status_id_TO_SYS_HIER_INFO وTSK_TASK_KEY_MON_TIME، ويتم استخدام فهرس المفتاح الخارجي في STATUS_ID عند تنفيذ العبارة أخيرًا.
دعونا نلقي نظرة أخرى على فهرس الجدول TSK_TASK:
+------------------------+----------- -- --------
|. الجدول |. اسم_العمود |
. -- ---------------
|. TSK_TASK |.المعرف 999149
|
.
-------------------------ضمن Oracle أو قواعد البيانات العلائقية الأخرى، حيث تلعب الشروط ترتيب الحقول في الفهرس دورًا مهمًا في اختيار الفهرس. دعونا نضبط ترتيب الحقول، ونضع STATUS_ID في النهاية، ونشرح مرة أخرى:
EXPLAIN حدد * من TSK_TASK WHERE MON_TIME >= '2007-11-22' وMON_TIME < '2007-11-23' وSTATUS_ID = 1064
؛ ليس هناك أي تأثير، لا يزال MySQL يستخدم فهرس المفاتيح الخارجية STATUS_ID الذي أنشأه النظام.
بعد التحليل الدقيق، يبدو أن السمة الأساسية (أي عدد القيم الفريدة في الفهرس) تلعب دورًا مهمًا للغاية في اختيار الفهرس في الفهرس كفهرس للبيان بأكمله.
بالنسبة لهذا البيان، إذا كنت تستخدم FK_task_status_id_TO_SYS_HIER_INFO كفهرس وقام جدول TSK_TASK بتخزين البيانات لعدة أيام، فسيكون عدد السجلات الممسوحة ضوئيًا كبيرًا وستكون السرعة بطيئة. هناك العديد من حلول التحسين المتاحة:
إذا لم يكن هناك العديد من المهام في يوم واحد، فإننا نحذف الفهرس FK_task_status_id_TO_SYS_HIER_INFO، ثم ستستخدم MySQL الفهرس TSK_TASK_KEY_MON_TIME، ثم نقوم بمسح السجلات باستخدام STATUS_ID 1064 في بيانات ذلك اليوم، وهو ليس بطيئًا. إذا
كان هناك العديد من المهام في يوم واحد، فسنحتاج إلى حذف الفهارس FK_task_status_id_TO_SYS_HIER_INFO وTSK_TASK_KEY_MON_TIME، ثم إنشاء فهرس مشترك لـ STATUS_ID، MON_TIME، والذي سيكون بالتأكيد فعالًا للغاية.
لذلك، يوصى بعدم استخدام المفاتيح الخارجية للجداول التي تحتوي على عدد كبير من السجلات لتجنب الانخفاض الخطير في كفاءة الأداء.
2. حاول التحكم في عدد السجلات في كل جدول.
عندما يكون عدد السجلات في الجدول كبيرًا، ستكون الإدارة والصيانة مزعجة للغاية. على سبيل المثال، ستستغرق صيانة الفهرس وقتًا طويلاً، مما سيؤدي إلى تعطيل كبير التشغيل العادي للنظام التدخل.
بالنسبة للجداول التي يستمر حجم بياناتها في النمو بمرور الوقت، يمكننا التمييز بين بيانات الوقت الفعلي والبيانات التاريخية بناءً على الوقت، ويمكننا استخدام برنامج خدمة الخلفية لنقل البيانات بشكل منتظم في جدول الوقت الفعلي إلى الجدول التاريخي، وبالتالي التحكم عدد السجلات في جدول الوقت الحقيقي وتحسين أداء الاستعلام والكفاءة التشغيلية. لكن لاحظ أن زمن كل خطوة يجب أن يكون قصيرا بما فيه الكفاية حتى لا تؤثر على كتابة بيانات البرنامج العادي. إذا استغرق الأمر وقتًا طويلاً، فقد يتسبب ذلك في حدوث مشكلة حالة توقف تام.
3. استراتيجية تجزئة (تقسيم) البيانات:
عندما يصل عدد العملاء إلى نطاق معين، لن تتمكن قاعدة بيانات واحدة من دعم وصول متزامن أعلى. في هذا الوقت، يمكنك التفكير في تجزئة (تقسيم) بيانات العميل إلى قواعد بيانات متعددة مشاركة الحمل تحسين الأداء العام وكفاءة النظام.