واليوم، يواصل المطورون تطوير التطبيقات ونشرها باستخدام بنية LAMP (Linux® وApache وMySQL وPHP/Perl). ومع ذلك، غالبًا ما يكون لمسؤولي الخادم سيطرة قليلة على التطبيقات نفسها لأن شخصًا آخر هو من قام بكتابة التطبيقات. تناقش هذه السلسلة المكونة من ثلاثة أجزاء عددًا من مشكلات تكوين الخادم التي يمكن أن تؤثر على أداء التطبيق. ستركز هذه المقالة، الجزء الثالث والأخير من هذه السلسلة، على ضبط طبقة قاعدة البيانات لتحقيق أقصى قدر من الكفاءة.
فيما يتعلق بضبط MySQL،
هناك ثلاث طرق لتسريع سرعة تشغيل خادم MySQL، وترتيب الكفاءة من الأقل إلى الأعلى هو:
استبدال الأجهزة التي بها مشكلات. اضبط إعدادات عملية MySQL. تحسين الاستعلام.
غالبًا ما يكون استبدال الأجهزة التي بها مشكلات هو أول اهتماماتنا، ويرجع ذلك أساسًا إلى أن قواعد البيانات يمكن أن تستهلك قدرًا كبيرًا من الموارد. لكن هذا الحل لا يذهب أبعد من ذلك. في الواقع، يمكنك في كثير من الأحيان مضاعفة سرعة وحدة المعالجة المركزية (CPU) أو القرص، وزيادة الذاكرة بمقدار 4 إلى 8 مرات.
الطريقة الثانية هي ضبط خادم MySQL (المعروف أيضًا باسم mysqld). ضبط هذه العملية يعني تخصيص الذاكرة بشكل مناسب والسماح لـ mysqld بمعرفة نوع التحميل الذي سيتعرض له. إن تسريع عملية القرص ليس بنفس أهمية تقليل عدد مرات الوصول المطلوبة إلى القرص. وبالمثل، فإن التأكد من أن عملية MySQL تعمل بشكل صحيح يعني أنها تقضي وقتًا أطول في خدمة الاستعلامات مقارنة بالمهام الخلفية مثل العمل مع جداول القرص المؤقتة أو فتح الملفات وإغلاقها. ضبط mysqld هو محور هذه المقالة.
أفضل طريقة هي التأكد من تحسين الاستعلام. وهذا يعني أنه يتم تطبيق الفهارس المناسبة على الجدول ويتم كتابة الاستعلامات بطريقة تستفيد بشكل كامل من إمكانيات MySQL. على الرغم من أن هذه المقالة لا تغطي ضبط الاستعلام (موضوع تمت تغطيته في العديد من الكتب)، إلا أنها تقوم بتكوين mysqld للإبلاغ عن الاستعلامات التي قد تحتاج إلى ضبط.
على الرغم من تعيين الترتيب لهذه المهام، إلا أنك لا تزال بحاجة إلى الانتباه إلى إعدادات الأجهزة وmysqld لضبط الاستعلام بشكل صحيح. لا بأس إذا كان الجهاز بطيئًا، لقد رأيت أن الأجهزة السريعة جدًا تفشل بسبب الحمل الثقيل عند تشغيل استعلامات مصممة جيدًا لأن mysqld كان مشغولًا بالكثير من العمل المزدحم ولم يتمكن من خدمة الاستعلام.
تسجيل الاستعلامات البطيئة
في خادم SQL، يتم تخزين جداول البيانات على القرص. توفر الفهارس للخادم طريقة للعثور على صفوف محددة من البيانات في جدول دون الحاجة إلى البحث في الجدول بأكمله. عندما يجب البحث في الجدول بأكمله، يطلق عليه فحص الجدول. بشكل عام، قد ترغب فقط في الحصول على مجموعة فرعية من البيانات الموجودة في الجدول، لذا فإن فحص الجدول بالكامل سيضيع الكثير من عمليات الإدخال/الإخراج على القرص، وبالتالي الكثير من الوقت. تتضاعف هذه المشكلة عندما يجب ضم البيانات، لأنه يجب مقارنة صفوف متعددة من البيانات على جانبي الصلة.
بالطبع، لا تتسبب عمليات فحص الجدول دائمًا في حدوث مشكلات؛ ففي بعض الأحيان يكون من الأفضل قراءة الجدول بأكمله بدلاً من تحديد مجموعة فرعية من البيانات (يتم استخدام مخطط الاستعلام في عملية الخادم لاتخاذ هذه القرارات). إذا تم استخدام الفهرس بشكل غير فعال، أو لا يمكن استخدامه على الإطلاق، فسيؤدي ذلك إلى إبطاء الاستعلامات، وستصبح هذه المشكلة أكثر أهمية مع زيادة التحميل على الخادم وحجم الجدول. تسمى الاستعلامات التي يستغرق تنفيذها وقتًا أطول من نطاق زمني محدد بالاستعلامات البطيئة.
يمكنك تكوين mysqld لتسجيل هذه الاستعلامات البطيئة إلى سجل استعلام بطيء مسمى بشكل مناسب. سيقوم المسؤولون بعد ذلك بمراجعة هذا السجل لمساعدتهم في تحديد أجزاء التطبيق التي تتطلب المزيد من التحقيق. تعرض القائمة 1 التكوين الذي يجب إجراؤه في my.cnf لتمكين تسجيل الاستعلام البطيء.
القائمة 1. تمكين سجل الاستعلام البطيء لـ MySQL
[mysqld]؛ استعلامات عدم استخدام الفهارس
يتم استخدام هذه الإعدادات الثلاثة معًا لتسجيل الاستعلامات التي يستغرق تنفيذها أكثر من 5 ثوانٍ ولا تستخدم الفهارس. يرجى ملاحظة التحذير بشأن عدم استخدام استعلامات السجل: يجب أن تستخدم MySQL 4.1 أو أعلى. يتم حفظ سجلات الاستعلام البطيء في دليل بيانات MySQL وتسمى hostname-slow.log. إذا كنت ترغب في استخدام اسم أو مسار مختلف، فيمكنك استخدام log-slow-queries = /new/path/to/file في my.cnf لتحقيق ذلك.
من الأفضل قراءة سجلات الاستعلام البطيئة من خلال الأمر mysqldumpslow. من خلال تحديد المسار إلى ملف السجل، يمكنك رؤية قائمة مرتبة من الاستعلامات البطيئة، بالإضافة إلى عدد مرات حدوثها في ملف السجل. الميزة المفيدة جدًا هي أن mysqldumpslow يزيل أي بيانات يحددها المستخدم قبل مقارنة النتائج، لذلك يتم احتساب الاستدعاءات المختلفة لنفس الاستعلام كواحدة، وهذا يمكن أن يساعد في تحديد الاستعلام الذي يتطلب معظم العمل.
استعلامات التخزين المؤقت
تعتمد العديد من تطبيقات LAMP بشكل كبير على قواعد البيانات ولكنها تنفذ نفس الاستعلامات مرارًا وتكرارًا. في كل مرة يتم فيها تنفيذ استعلام، يجب أن تؤدي قاعدة البيانات نفس الوظيفة - تحليل الاستعلام، وتحديد كيفية تنفيذه، وتحميل المعلومات من القرص، وإرجاع النتائج إلى العميل. يحتوي MySQL على ميزة تسمى ذاكرة التخزين المؤقت للاستعلام، والتي تخزن نتائج الاستعلام (والتي سيتم استخدامها لاحقًا) في الذاكرة. في كثير من الحالات، سيؤدي ذلك إلى تحسين الأداء بشكل كبير. لكن المشكلة هي أن التخزين المؤقت للاستعلام معطل افتراضيًا.
أضف query_cache_size = 32M إلى /etc/my.conf لتمكين ذاكرة تخزين مؤقت للاستعلام تبلغ 32 ميجابايت.
مراقبة ذاكرة التخزين المؤقت للاستعلام
بعد تمكين ذاكرة التخزين المؤقت للاستعلام، من المهم فهم ما إذا كان يتم استخدامها بشكل فعال. يحتوي MySQL على العديد من المتغيرات التي يمكنك الاطلاع عليها لفهم ما يجري في ذاكرة التخزين المؤقت. تعرض القائمة 2 حالة ذاكرة التخزين المؤقت.
القائمة 2. عرض إحصائيات ذاكرة التخزين المؤقت للاستعلام
Mysql> إظهار الحالة مثل 'qcache%'؛+----------------------------------------------------+ |.اسم المتغير |.القيمة |+------------------------+-----------+| |.Qcache_free_memory ||.Qcache_hits ||.Qcache_total_blocks || 7042 |+------------- -------- ---+----------------+8 صفوف في المجموعة (0.00 ثانية)
ويرد شرح هذه العناصر في الجدول 1.
الجدول 1. وصف اسم متغير ذاكرة التخزين المؤقت لاستعلام MySQL
Qcache_free_blocks عدد كتل الذاكرة المجاورة في ذاكرة التخزين المؤقت. يشير العدد الكبير إلى احتمال وجود أجزاء. يقوم FLUSH QUERY CACHE بإلغاء تجزئة ذاكرة التخزين المؤقت للحصول على كتلة مجانية.
Qcache_free_memory الذاكرة الحرة في ذاكرة التخزين المؤقت.
تتم زيادة Qcache_hits في كل مرة يصل فيها الاستعلام إلى ذاكرة التخزين المؤقت.
تتم زيادة Qcache_inserts في كل مرة يتم فيها إدراج استعلام. نسبة الخطأ هي عدد مرات الدخول مقسومًا على عدد عمليات الإدراج؛ اطرح هذه القيمة من 1 للحصول على معدل الإصابة. في المثال أعلاه، وصلت حوالي 87% من الاستعلامات إلى ذاكرة التخزين المؤقت.
Qcache_lowmem_prunes عدد المرات التي نفدت فيها ذاكرة التخزين المؤقت وكان لا بد من إزالتها لإفساح المجال لمزيد من الاستعلامات. من الأفضل عرض هذا الرقم على مدى فترة طويلة من الزمن؛ إذا كان العدد في ازدياد، فقد يشير ذلك إلى تجزئة شديدة أو انخفاض في الذاكرة. (يمكن أن يخبرك free_blocks وfree_memory أعلاه بالحالة التي هي عليها).
Qcache_not_cached عدد الاستعلامات غير المناسبة للتخزين المؤقت، عادةً لأنها ليست عبارات SELECT.
Qcache_queries_in_cache عدد الاستعلامات (والاستجابات) المخزنة مؤقتًا حاليًا.
Qcache_total_blocks عدد الكتل في ذاكرة التخزين المؤقت.
في كثير من الأحيان يمكن ملاحظة الفرق من خلال عرض هذه المتغيرات بفارق ثواني قليلة، مما يمكن أن يساعد في تحديد ما إذا كان يتم استخدام ذاكرة التخزين المؤقت بكفاءة. يمكن أن يؤدي تشغيل FLUSH STATUS إلى إعادة تعيين بعض العدادات، وهو ما قد يكون مفيدًا للغاية إذا كان الخادم قيد التشغيل لفترة من الوقت.
من المغري جدًا استخدام ذاكرة تخزين مؤقت كبيرة جدًا للاستعلام وتوقع تخزين كل شيء مؤقتًا. نظرًا لأنه يجب على mysqld إجراء صيانة على ذاكرة التخزين المؤقت، مثل إجراء التنقيح عندما تصبح الذاكرة منخفضة، فقد يتعثر الخادم في محاولة إدارة ذاكرة التخزين المؤقت. كقاعدة عامة، إذا استغرق مسح ذاكرة التخزين المؤقت للاستعلام وقتًا طويلاً، فهذا يعني أن ذاكرة التخزين المؤقت كبيرة جدًا.
فرض الحدود
يمكنك فرض الحدود في mysqld للتأكد من أن تحميل النظام لا يسبب استنفاد الموارد. تعرض القائمة 3 بعض الإعدادات المهمة المتعلقة بالموارد في my.cnf.
القائمة 3. إعدادات موارد MySQL
مجموعة المتغير=max_connections=500set-variable=wait_timeout=10max_connect_errors = 100
تتم إدارة الحد الأقصى لعدد الاتصالات في السطر الأول. كما هو الحال مع MaxClients في Apache، تتمثل الفكرة في التأكد من إجراء عدد الاتصالات الذي تسمح به الخدمة فقط. لتحديد الحد الأقصى لعدد الاتصالات التي تم إنشاؤها حاليًا على الخادم، قم بتنفيذ SHOW STATUS LIKE 'max_used_connections'.
يخبر السطر 2 mysqld بإنهاء أي اتصالات كانت خاملة لأكثر من 10 ثوانٍ. في تطبيق LAMP، عادةً ما يكون الوقت الذي يستغرقه الاتصال بقاعدة البيانات هو الوقت الذي يستغرقه خادم الويب لمعالجة الطلب. في بعض الأحيان، إذا كان الحمل ثقيلًا جدًا، فسيتوقف الاتصال وسيشغل مساحة على جدول الاتصال. إذا كان لديك عدة مستخدمين تفاعليين أو تستخدم اتصالات مستمرة بقاعدة البيانات، فمن غير المستحسن تعيين هذه القيمة أقل!
السطر الأخير هو طريقة آمنة. إذا واجه المضيف مشكلات في الاتصال بالخادم وأعاد المحاولة عدة مرات قبل الاستسلام، فسيتم قفل المضيف ولا يمكن تشغيله إلا بعد FLUSH HOSTS. افتراضيًا، تكفي 10 حالات فشل للتسبب في الإغلاق. سيؤدي تغيير هذه القيمة إلى 100 إلى منح الخادم وقتًا كافيًا للتعافي من المشكلة. إذا تعذر إنشاء الاتصال بعد 100 عملية إعادة محاولة، فإن استخدام قيمة أعلى لن يساعد كثيرًا وقد لا يتم الاتصال على الإطلاق.
المخازن المؤقتة والتخزين المؤقت
يدعم MySQL أكثر من 100 إعداد قابل للتعديل، ولكن لحسن الحظ، فإن إتقان القليل منها سوف يلبي معظم الاحتياجات. للعثور على القيم الصحيحة لهذه الإعدادات، يمكنك عرض متغيرات الحالة من خلال أمر SHOW STATUS، والذي يمكنه تحديد ما إذا كان mysqld يعمل كما نتوقع. لا يمكن أن تتجاوز الذاكرة المخصصة للمخازن المؤقتة وذاكرة التخزين المؤقت الذاكرة المتوفرة على النظام، لذا يتطلب الضبط عادةً بعض التنازلات.
يمكن تطبيق إعدادات MySQL القابلة للضبط على عملية mysqld بأكملها أو على جلسات العميل الفردية.
إعدادات جانب الخادم
يمكن تمثيل كل جدول كملف على القرص، والذي يجب فتحه أولاً ثم قراءته. لتسريع عملية قراءة البيانات من الملفات، يقوم mysqld بتخزين هذه الملفات المفتوحة مؤقتًا حتى الحد الأقصى المحدد بواسطة table_cache في /etc/mysqld.conf. تعرض القائمة 4 طريقة لعرض النشاط المتعلق بفتح الجدول.
القائمة 4. عرض الأنشطة التي تفتح الجداول
mysql> عرض الحالة مثل 'open%tables';+---------+-------+| Variable_name |+-------- -------+-------+|. Open_tables |. 5000 ||. +2 صفين في المجموعة (0.00 ثانية)
توضح القائمة 4 أن هناك حاليًا 5000 جدول مفتوح وأن 195 جدولًا بحاجة إلى فتح لأنه لا توجد واصفات ملفات متاحة في ذاكرة التخزين المؤقت (بما أنه تم مسح الإحصائيات مسبقًا، فقد يكون هناك 5000 جدول مفتوح فقط). . إذا زادت Opened_tables بسرعة مع إعادة تشغيل أمر SHOW STATUS، فهذا يشير إلى أن معدل دخول ذاكرة التخزين المؤقت غير كافٍ. إذا كان Open_tables أصغر بكثير من إعداد table_cache، فإن القيمة كبيرة جدًا (ولكن وجود مساحة للنمو ليس أمرًا سيئًا على الإطلاق). على سبيل المثال، استخدم table_cache = 5000 لضبط ذاكرة التخزين المؤقت للجدول.
كما هو الحال مع ذاكرة التخزين المؤقت للجدول، هناك أيضًا ذاكرة تخزين مؤقت لسلاسل الرسائل. يقوم mysqld بتوليد الخيوط حسب الحاجة عند تلقي الاتصالات. على خادم مزدحم حيث تتغير الاتصالات بسرعة، يمكن أن يؤدي تخزين سلاسل الرسائل مؤقتًا لاستخدامها لاحقًا إلى تسريع الاتصال الأولي.
توضح القائمة 5 كيفية تحديد ما إذا كان هناك ما يكفي من المواضيع المخزنة مؤقتًا.
القائمة 5. عرض إحصائيات استخدام الموضوع
mysql> إظهار الحالة مثل 'threads%';+-------------------+--------+| Variable_name |+---- ---------------+-------+|. Threads_connected 15 ||. ---------------+--------+4 صفوف في المجموعة (0.00 ثانية)
القيمة المهمة هنا هي Threads_created، وتزداد هذه القيمة في كل مرة يحتاج فيها MySQL إلى إنشاء موضوع جديد. إذا زاد هذا الرقم بسرعة عند تنفيذ أوامر SHOW STATUS المتعاقبة، فيجب أن تحاول زيادة ذاكرة التخزين المؤقت لمؤشر الترابط. على سبيل المثال، يمكنك استخدام thread_cache = 40 في my.cnf لتحقيق ذلك.
يحتفظ المخزن المؤقت الرئيسي بكتلة الفهرس لجدول MyISAM. ومن الناحية المثالية، يجب أن تأتي طلبات هذه الكتل من الذاكرة وليس من القرص. توضح القائمة 6 كيفية تحديد عدد الكتل التي تمت قراءتها من القرص وعدد الكتل التي تمت قراءتها من الذاكرة.
القائمة 6. تحديد كفاءة الكلمات الرئيسية
mysql> عرض الحالة مثل '%key_read%';+-------------------+-----------+|Variable_name |+ ------------------+---------+|Key_read_requests ||. -----------+-----------+ صفين في المجموعة (0.00 ثانية)
يمثل Key_reads عدد الطلبات التي تصل إلى القرص، وKey_read_requests هو العدد الإجمالي. نسبة الخطأ هي عدد طلبات القراءة التي تصل إلى القرص مقسومًا على إجمالي عدد طلبات القراءة - في هذه الحالة حوالي 0.6 خطأ في الذاكرة لكل 1000 طلب. إذا تجاوز عدد مرات الوصول إلى القرص مرة واحدة لكل 1000 طلب، فيجب أن تفكر في زيادة المخزن المؤقت للكلمات الرئيسية. على سبيل المثال، key_buffer = 384M سوف يضبط المخزن المؤقت على 384 ميجابايت.
يمكن استخدام الجداول المؤقتة في الاستعلامات الأكثر تقدمًا حيث يجب حفظ البيانات في جدول مؤقت قبل إجراء المزيد من المعالجة (مثل عبارة GROUP BY، ومن الناحية المثالية، يتم إنشاء الجدول المؤقت في الذاكرة). ولكن إذا أصبح الجدول المؤقت كبيرًا جدًا، فيجب كتابته على القرص. توفر القائمة 7 إحصائيات متعلقة بإنشاء الجدول المؤقت.
القائمة 7. تحديد استخدام الجداول المؤقتة
mysql> عرض الحالة مثل 'created_tmp%'؛+-------------------------+-------+|Variable_name | |-------------------------+-------+|.Created_tmp_tables | |. +-----+-----------------------+3 صفوف في المجموعة (0.00 ثانية)
سيتم زيادة Created_tmp_tables في كل مرة يتم فيها استخدام جدول مؤقت؛ كما سيتم زيادة Created_tmp_disk_tables للجداول المستندة إلى القرص. لا توجد قواعد صارمة لهذه النسبة، لأنها تعتمد على الاستعلام المعني. ستظهر لك مشاهدة Created_tmp_disk_tables مع مرور الوقت نسبة جداول القرص التي تم إنشاؤها ويمكنك تحديد كفاءة الإعداد الخاص بك. يتحكم كل من tmp_table_size وmax_heap_table_size في الحد الأقصى لحجم الجداول المؤقتة، لذا تأكد من تعيين القيمتين في my.cnf.
إعدادات كل جلسة
الإعدادات التالية خاصة بكل جلسة. كن حذرًا جدًا عند تعيين هذه الأرقام لأنه عند ضربها بعدد الاتصالات التي قد تكون موجودة، تمثل هذه الخيارات مقدارًا كبيرًا من الذاكرة! يمكنك تعديل هذه الأرقام خلال الجلسة من خلال الكود، أو تعديل هذه الإعدادات في my.cnf لجميع الجلسات.
عندما يتعين على MySQL الفرز، فإنه يخصص مخزنًا مؤقتًا للفرز للاحتفاظ بصفوف البيانات أثناء قراءتها من القرص. إذا كانت البيانات المراد فرزها كبيرة جدًا، فيجب حفظ البيانات في ملف مؤقت على القرص وفرزها مرة أخرى. إذا كان متغير الحالةsort_merge_passes كبيرًا، فهذا يشير إلى نشاط القرص. تعرض القائمة 8 بعض معلومات عداد الحالة المتعلقة بالفرز.
قائمة 8. عرض إحصائيات الفرز
mysql> عرض الحالة مثل "sort%";+---+-----------------------+| Variable_name |+--- ----------------+--------+|. Sort_range |. 79192 ||. --+-------------------------+4 صفوف في المجموعة (0.00 ثانية)
إذا كانت قيمةsort_merge_passes كبيرة، فهذا يعني أنك بحاجة إلى الانتباه إلى size_buffer_size. على سبيل المثال، يقومsort_buffer_size = 4M بتعيين المخزن المؤقت للفرز على 4 ميجابايت.
يخصص MySQL أيضًا بعض الذاكرة لقراءة الجدول. من الناحية المثالية، يوفر الفهرس معلومات كافية لقراءة الصفوف التي تحتاجها فقط، ولكن في بعض الأحيان يحتاج الاستعلام (سيئ التصميم أو بسبب طبيعة البيانات) إلى قراءة كمية كبيرة من البيانات من الجدول. لفهم هذا السلوك، تحتاج إلى معرفة عدد عبارات SELECT التي تم تشغيلها وعدد المرات التي يلزم فيها قراءة الصف التالي من البيانات في الجدول (بدلاً من الوصول إليه مباشرة من خلال الفهرس). يظهر الأمر لتحقيق هذه الوظيفة في القائمة 9.
القائمة 9. تحديد نسبة مسح الجدول
mysql> عرض الحالة مثل "com_select"؛+---------+--------+| Variable_name |+--------- ------+--------+|. Com_select |. 318243 |+----------+--------+صف واحد في المجموعة (0.00 ثانية) mysql> عرض الحالة مثل "handler_read_rnd_next";+-----------------------+----------- +| Variable_name | |+-----------------------+---------+|. Handler_read_rnd_next |. --+-------------------------+صف واحد في المجموعة (0.00 ثانية)
يؤدي Handler_read_rnd_next / Com_select إلى نسبة مسح الجدول - في هذه الحالة 521:1. إذا تجاوزت القيمة 4000، يجب عليك التحقق من read_buffer_size، على سبيل المثال read_buffer_size = 4M. إذا تجاوز هذا الرقم 8 ملايين، فقد حان الوقت لمناقشة ضبط هذه الاستعلامات مع المطورين!
3 أدوات أساسية
على الرغم من أن الأمر SHOW STATUS يمكن أن يكون مفيدًا جدًا عند فهم إعداد معين، إلا أنك ستحتاج أيضًا إلى بعض الأدوات لتفسير الكميات الكبيرة من البيانات التي يوفرها mysqld. هناك ثلاث أدوات أجدها ضرورية؛ يمكنك العثور على روابط لها في قسم الموارد.
معظم مسؤولي النظام على دراية بالأمر العلوي، الذي يوفر عرضًا محدثًا باستمرار لوحدة المعالجة المركزية والذاكرة التي تستهلكها المهام. يحاكي mytop الجزء العلوي؛ فهو يوفر عرضًا لجميع العملاء المتصلين والاستعلامات التي يقومون بتشغيلها. يوفر mytop أيضًا بيانات حية وتاريخية حول المخزن المؤقت للكلمات الرئيسية وكفاءة ذاكرة التخزين المؤقت للاستعلام، بالإضافة إلى إحصائيات حول تشغيل الاستعلامات. هذه أداة مفيدة لمعرفة ما يحدث في نظامك (على سبيل المثال، في غضون 10 ثوانٍ)، ويمكنك الحصول على عرض لمعلومات صحة الخادم وإظهار أي اتصالات تسبب مشاكل.
mysqlard هو برنامج خفي متصل بخادم MySQL، وهو مسؤول عن جمع البيانات كل 5 دقائق وتخزينها في قاعدة بيانات Round Robin في الخلفية. توجد صفحة ويب تعرض بيانات مثل استخدام ذاكرة التخزين المؤقت للجدول وكفاءة الكلمات الرئيسية والعملاء المتصلين واستخدام الجدول المؤقت. على الرغم من أن mytop يوفر لمحة سريعة عن معلومات صحة الخادم، إلا أن mysqlard يوفر معلومات صحية طويلة المدى. كمكافأة، يستخدم mysqlard بعض المعلومات التي جمعها لتقديم بعض الاقتراحات حول كيفية ضبط الخادم.
هناك أداة أخرى لجمع معلومات حالة العرض وهي mysqlreport. تعد تقاريرها أكثر تعقيدًا بكثير من تقارير mysqlard لأن كل جانب من جوانب الخادم يحتاج إلى التحليل. تعد هذه أداة رائعة لضبط الخادم الخاص بك لأنها تقوم بإجراء العمليات الحسابية المناسبة على متغيرات الحالة للمساعدة في تحديد المشكلات التي تحتاج إلى إصلاح.
الاستنتاج
قدمت هذه المقالة بعض المعرفة الأساسية حول ضبط MySQL واختتمت هذه السلسلة المكونة من ثلاثة أجزاء حول ضبط مكونات LAMP. يتضمن الضبط إلى حد كبير فهم كيفية عمل المكونات، وتحديد ما إذا كانت تعمل بشكل صحيح، وإجراء بعض التعديلات، وإعادة التقييم. كل مكون - Linux أو Apache أو PHP أو MySQL - له متطلبات مختلفة. يمكن أن يساعد فهم كل مكون على حدة في تقليل الاختناقات التي يمكن أن تؤدي إلى إبطاء تطبيقك.