كيفية تشكيل استعلامات SQL للحصول على أداء أفضل

في Servebolt ، نعيش ونتنفسالأداء .

أداء قاعدة البيانات ليس استثناء.

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

Time to First Byte (TTFB) هي طريقة لقياس الوقت الذي يستغرقه استلام البايت الأول من البيانات بعد قيام المستخدم بتقديم طلب إلى موقع ويب.إنه أيضًا مقياس رئيسي تستخدمه محركات البحث في تقييم المواقع. عندما يتم تشغيل استعلام بطيء ، فإنه سيؤثر سلبًا على TTFB. كلما طالت مدة تشغيل الاستعلام البطيء ، كلما ارتفع TTFB ، مما يؤدي إلى أداء أبطأ لموقع الويب بشكل عام وتجربة مستخدم أقل إرضاءً.

في هذا الدليل ، سنرشدك إلى كيفية تكوين ملف تعريف استعلامات SQL - وهي جزء أساسي من الحفاظ على أداء تطبيقات الويب التي تعتمد على استجابات قاعدة البيانات. هذه عملية تضع الأساس لتكون قادرًا بعد ذلك على بدء العمل على تحسين هذه الاستعلامات لتحسين أدائها.

فهم تشكيل استعلام SQL

أثناء قيامك بتطوير تطبيق ويب وبدء تشغيله على نطاق أوسع ، يمكن أن تتسبب استعلامات SQL التي كانت تعمل بسلاسة في السابق في حدوث مشكلات في الأداء. بشكل عام ، هناك عدد متزايد من الاستعلامات التي تعمل مقابل كمية متزايدة من البيانات مع عدد متزايد من الطلبات في الثانية. وعندما يتأثر الأداء ، تتأثر أيضًا تجربة المستخدمين عند التفاعل مع موقعك أو برنامجك أو خدمتك.

يعد تحديد سمات الاستعلام طريقة لتحليل استعلامات قاعدة البيانات وتقييم أدائها وتحديد المشكلات المحتملة.

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

توفر MariaDB (و MySQL) العديد من الأدوات والتقنيات لتوصيف الاستعلام ، والتي سنغطيها في هذه المقالة. بمجرد تحديد الاستعلامات البطيئة ، ستكون الخطوة التالية هي تحسينها. تتضمن هذه العملية تحديد السبب الجذري للمشكلة ، وإجراء تغييرات على هيكل الاستعلامات لتحسين كفاءتها.

كيفية ملف تعريف استعلامات SQL (7 طرق)

لنبدأ بتفصيل الأدوات والتقنيات المختلفة المتاحة لتحديد الاستعلامات البطيئة وغير الفعالة حتى تعرف أين تركز جهود التحسين:

1 - شرح الأمرالموسع

أحد الأدوات التي يمكن استخدامها لتحليل استعلامات SQL الخاصة بك هو أمرشرح .

من خلال تشغيل الأمر EXPLAIN في استعلام ، يمكنك رؤية كيفية تنفيذ الاستعلام ، بما في ذلك الفهارس المستخدمة وعدد الصفوف التي تم فحصها.

EXPLAIN SELECT * FROM orders

JOIN customers ON orders.customer_id = customers.customer_id

WHERE customers.name = 'John Smith';

عند تشغيل الأمر EXPLAINفي استعلام ، فإنه يقوم بإرجاع مجموعة نتائج مكونة من عدة أعمدة ، بما في ذلك:

• المعرّف: المعرّف الفريد للاستعلام في خطة التنفيذ
• select_type: نوع الاستعلام ، مثل SIMPLE أو SUBQUERY
• الجدول: الجدول الذي يتم الاستعلام عنه
• النوع: نوع الصلة المستخدم ، مثل JOIN أو INDEX
• possible_keys: الفهارس التي كان من الممكن أن يستخدمها MariaDB أو MySQL لمعالجة الاستعلام
• المفتاح: الفهرس الذي استخدمته MariaDB أو MySQL بالفعل لمعالجة الاستعلام
• key_len: طول المفتاح الذي تم استخدامه
• الصفوف: عدد الصفوف التي ستُفحص بها تقديرات MariaDB أو MySQL للاستعلام

إضافي: يحتوي هذا على معلومات إضافية حول الاستعلام ، مثل ما إذا كان قد تم إجراء مسح كامل للجدول أو ما إذا كان قد تم استخدام جدول مؤقت.

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

على سبيل المثال ، إذا كان عمود النوع يعرض "الكل" بدلاً من "الفهرس" ، فحينئذٍ يقوم الاستعلام بإجراء مسح كامل للجدول ، والذي سيؤدي بالتأكيد إلى بطء الأداء. إذا كان عمود المفتاح NULL ، فإن MySQL لا تستخدم أي فهارس ، والتي ستكون بطيئة أيضًا. إذا كان لعمود الصفوف قيمة عالية ، فهذا يعني أنه يتم فحص العديد من الصفوف ، مما يؤدي إلى مزيد من التدهور في الأداء.

نحن نفضل استخدام الاختلاف EXPLAIN EXTENDED للمساعدة في توفير معلومات إضافية.

ملاحظة: بينما تم إهمال هذا في MySQL ، فإنه لا يزال متاحًا في MariaDB.

باستخدام خيار EXTENDED ، ستتمكن من رؤية معلومات مفيدة مثل عدد الصفوف التي تم فحصها ، وعدد الصفوف التي تم إرجاعها ، ومعلومات حول نوع JOIN المستخدم ، وترتيب الجداول الممسوحة ضوئيًا ، والفهارس المستخدمة ، وطول المدة استغرق الاستعلام ليتم تنفيذه.

إليك كيف يبدو استخدام الأمر EXPLAIN EXTENDED:

EXPLAIN EXTENDED SELECT * FROM your_table WHERE column_name = 'value';

في هذا المثال ، سيعرض الأمر EXPLAIN قائمة بالخطوات التي ستتخذها قاعدة البيانات من أجل تنفيذ الاستعلام ، بالإضافة إلى قائمة بالموارد التي ستستخدمها.

باستخدام هذا الأمر ، ستتمكن بسهولة أكبر من تحديد الاختناقات في الاستعلام ، مما يسمح لك بإجراء أي تغييرات ضرورية ستساعد في التخفيف من ذلك وتسريع أداء الاستعلام.

على سبيل المثال ، يمكن أن يساعد استخدام الأمر EXPLAIN EXTENDED في تحديد الحاجة إلى إضافة فهارس ، وتحسين شروط JOIN ، والحد من العدد الإجمالي للصفوف التي يتم إرجاعها بواسطة الاستعلام.

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

SET SESSION query_cache_type=0;

بمجرد إجراء هذه التغييرات على استعلامك ، اختبر أدائه مرة أخرى لتحديد مقدار التحسين الذي تم تحقيقه (إن وجد). تذكر أنه ، كما هو الحال مع أي ملف تعريف وتحسين لاستعلام ، فإن العملية تكرارية - توقع استخدام الأمر EXPLAIN EXTENDED ، متبوعًا باختبار الأداء ، عدة مرات.

2 - شرح تحليلالأمر

يستخدم هذا الأمر لتحليل خطة تنفيذ الاستعلام وإرجاع مقاييس الأداء مثل الوقت الفعلي الذي استغرقه الاستعلام في التنفيذ وعدد الصفوف التي تم فحصها بالفعل. من خلال تحليل نتائج الأمر EXPLAIN ANALYZE ، يمكنك تحديد أي اختناقات محتملة في تنفيذ الاستعلام ، مثل نقص الفهارس أو وجود عدد كبير من الصفوف التي يجب فحصها.

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

هذه ميزة مضمنة في MariaDB (و MySQL) تسجل جميع الاستعلامات التي تستغرق وقتًا أطول من وقت معين للتنفيذ. يمكن تكوين سجل الاستعلام البطيء لتسجيل الاستعلامات التي تستغرق وقتًا أطول من حد معين ، مثل ثانية واحدة.

في Servebolt ، يسجل سجل الاستعلام البطيء جميع الاستعلامات التي تستغرق أكثر من ثانية واحدة للتنفيذ. وذلك لأن معظم الاستعلامات يجب أن يتم تنفيذها في أجزاء من الثانية. في سياق تطبيق ويب ، مثل موقع يقوم بتشغيل WordPress ، يتطلب تحميل صفحة واحدة ما بين 10 و 100 استعلام عن قاعدة البيانات ، وكلها يجب تنفيذها بالتسلسل قبل أن يتم تجميع الصفحة إلى HTML وإعادتها إلى المستخدم.

يحتفظ تكوين Servebolt Cloud الحالي بسجلات الاستعلام البطيئة على خادم السجل العام. إذا دعت الحاجة ، يمكنك ببساطة الاتصال بفريق الدعم الخاص بنا ، وسنقوم بتصفية الملف للسجلات ذات الصلة ونزودك بالمخرجات.

في بيئاتك الخاصة ، يمكنك تمكين سجل الاستعلام البطيء عن طريق إضافة الأسطر التالية إلى ملف تكوين MariaDB أو MySQL (my.cnf أو my.ini):

log_slow_queries = /path/to/slow.log

long_query_time = 1

4 - مخطط الشرح المرئي

توفر خطة الشرح المرئي تمثيلاً رسوميًا لإخراج الأمر EXPLAIN ، مما يسهل فهم تنفيذ الاستعلام واكتشاف أي مشاكل في الأداء.

ملاحظة: تعد خطط التفسير المرئي مفيدة عندما تكون في طور تطوير تطبيقات الويب.

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

يمكن للأدوات المختلفة ، مثل MySQL Workbench و EXPLAIN Analyzer، إنشاء خطط شرح مرئية ، وتقديم واجهة تفاعلية للتنقل في خطة التنفيذ وفحص كل عملية بالتفصيل.

على سبيل المثال ، في MySQL Workbench ، يكون إنشاء خطة شرح مرئية أمرًا بسيطًا مثل تنفيذ الاستعلام والنقر فوق الزر "شرح الخطة " في علامة تبويب النتيجة.يقدم هذا تمثيلًا رسوميًا لخطة تنفيذ الاستعلام ، جنبًا إلى جنب مع معلومات مفصلة عن كل عملية. يمكّنك هذا من تحديد أي مشكلات في الأداء ثم تحسين الاستعلام حسب الحاجة.

5 - موالف MySQL

MySQL Tuner هو برنامج نصي يتحقق من أداء وتكوين خادم قاعدة البيانات ويقدم توصيات للتحسين. يوفر ملخصًا لحالة الخادم الحالية ، بما في ذلك معلومات مثل العدد الإجمالي للاستعلامات وعدد الاستعلامات البطيئة واستخدام تجمع المخزن المؤقت الحالي.

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

يتمثل أحد الاختلافات الرئيسية مع الأدوات الأخرى في أنها أداة سطر أوامر يمكن تشغيلها إما على الخادم نفسه أو عن بُعد ، مما يجعل من السهل أتمتة عملية مراقبة أداء قاعدة البيانات وتحسينه.

ملاحظة: إذا كان تطبيق الويب (وقاعدة البيانات) الخاصين بك مستضافين بالفعل في Servebolt Cloud - فهذا شيء يتخصص فيه فريقنا ويستطيع القيام به بشكل أفضل من أي توصيات يمكن للأداة تقديمها.

6 - الاستعلام عن ملفات التعريف

هناك برامج تعريف استعلام لجهات خارجية يمكن استخدامها لتوصيف استعلامات SQL ، مثل MariaDB Enterprise Query Analyzer و Dataedo و Percona Toolkit . يمكن أن توفر ملفات تعريف الاستعلام التابعة لجهات خارجية ميزات ووظائف إضافية مقارنة بالأدوات المضمنة المتوفرة في MariaDB (أو MySQL).

ملاحظة: تكون ملفات تعريف الاستعلام مفيدة عندما تكون بصدد تطوير تطبيقات الويب.

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

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

7 - التنميط بأدوات المراقبة

هناك أيضًا عدد من أدوات المراقبة ، مثل Prometheus و Grafana و Nagios ، والتي يمكن استخدامها لملف تعريف الاستعلامات ومراقبة أداء قواعد البيانات الخاصة بك.

Prometheus هو نظام مراقبة فعال يمكنه جمع بيانات المقاييس وتخزينها والاستعلام عنها ، مما يسمح لك باكتساب رؤى قيمة في الوقت الفعلي.يتكامل مع MariaDB (و MySQL) لتخزين المقاييس التي تم جمعها ويأتي مع Grafana للتصور الفعال.

Grafana هي أداة تحليلات قوية ومفتوحة المصدر يمكن استخدامها لمراقبة وتصور البيانات التي تم جمعها من بروميثيوس.يتيح لك إعداد التنبيهات ولوحات المعلومات المخصصة مراقبة أداء قاعدة البيانات في الوقت الفعلي.

يساعدكNagios في مراقبة صحة قاعدة البيانات الخاصة بك في جميع الأوقات.يمكن إعداده لمراقبة الموارد الرئيسية مثل وحدة المعالجة المركزية وذاكرة الوصول العشوائي ومساحة القرص ، مع تتبع الخدمات وأجهزة الشبكة الأخرى أيضًا. نظرًا لأنه قابل للتكوين بدرجة كبيرة ، فإنه يعد أداة رائعة لمراقبة استعلام قاعدة البيانات الاستباقي.

بمساعدة أدوات مراقبة الخادم هذه ، يمكنك تتبع مشكلات الأداء واتخاذ الإجراءات بسرعة ، مما يتيح لك التأكد من أن خادم قاعدة البيانات يعمل بسلاسة.

تقنيات تحسين الاستعلام الشائعة

هناك العديد من تقنيات تحسين الاستعلام الشائعة التي يمكن استخدامها لتحسين أداء استعلامات SQL:

1 - الفهرسة

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

على سبيل المثال ، ضع في اعتبارك جدولًا كبيرًا يسمى "الطلبات" يحتوي على ملايين صفوف البيانات ، بما في ذلك معلومات مثل معرف الطلب ومعرف العميل وتاريخ الطلب. إذا تم تنفيذ استعلام لاسترداد جميع الطلبات المقدمة من قبل عميل معين دون فهرس في عمود معرّف العميل ، فسيتعين على MariaDB مسح الجدول بأكمله لتحديد موقع البيانات ذات الصلة. قد يستغرق هذا وقتًا وموارد كبيرة ، خاصة للجداول الكبيرة.

بشكل عام ، كلما كنت واثقًا من أنك ستجري استعلامًا محددًا بشكل متكرر وتقرأ أهمية الأداء ، فإن إنشاء فهرس (أو أكثر من واحد) يمكن أن يكون الطريقة الصحيحة لتسريع هذا الاستعلام.

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

لعرض أي فهارس موجودة في جدول معين ،

يمكنك عرض أي فهارس موجودة في جدول معين باستخدام SHOW INDEX FROM - كما في المثال أدناه لجدول wp_postmeta:

MariaDB [db_name] > SHOW INDEX FROM wp_postmeta;

في أحد السيناريوهات ، أنشأنا مؤخرًا فهرسين لجدول wp_postmeta:sb_postid_metakey و sb_postid_metakey_metaval.

تمت إضافة هذه الفهارس بناءً على النظر في أهم الاستعلامات البطيئة ووجد أنها كانت متشابهة نسبيًا من خلال خاصية كونها عبارات SELECT التي تقوم بالتصفية باستخدام WHERE بالإضافة إلى الكثير من شروط المقارنة (AND / OR). عند رؤية هذا ، قمت بمراجعة الفهارس الحالية للجدول المستخدم وقمت بتشغيلEXPLAIN EXTENDED على الاستعلام للتحقق من صحة النهج الذي أتبعه بشكل أكبر.

كان الاستعلام يعمل في الغالب ويستخدم جدول wp_postmeta باستخدامJOIN.بناءً على الترتيب الذي حدث به ذلك ، فإن إضافة هذه الفهارس ستسمح لـ MariaDB (أو MySQL) بالحصول على استجابتها من الفهارس بدلاً من مسح الجدول بأكمله بكل صفوفه.

CREATE INDEX sb_postid_metakey ON wp_postmeta (post_id, meta_key);

CREATE INDEX sb_postid_metakey_metaval ON wp_postmeta (post_id, meta_key, meta_value);

هذا هو مزيج من "اكتشاف الأشياء" باستخدام الأدوات المتاحة لك (كما هو موضح أعلاه) ، بالإضافة إلى معرفة أنواع البيانات ومحتويات قاعدة البيانات. هذا لا يعمل دائما بأي حال من الأحوال. حتى عندما يحدث ذلك ، فإنه لا يؤدي دائمًا إلى تحسين الأداء بنسبة 500٪. يمكن أن يؤدي وجود فهرس ضخم إلى أن يكون أبطأ من مسح جميع الصفوف ، لذلك يجب اختبار الاستعلامات قبل وبعد تطبيق الفهارس للتأكد.

ملاحظة: عند محاولة اختبار سرعات الفهرس ، ستحتاج إلى تعطيل التخزين المؤقت للاستعلام للجلسة ، باستخدام:

SET SESSION query_cache_type=0;

في هذه الحالة ، قبل استخدام الفهارس ، استغرق الاستعلام 10.437 ثانية للتنفيذ. وبعد إنشاء الفهرين ، استغرق الاستعلام نفسه [# من الثواني].

2 - الحد من الوصول إلى البيانات

تقليل الوصول إلى البيانات ، أي تقليل عدد الصفوف والأعمدة التي سيتم الوصول إليها لتنفيذ استعلام.يمكن تحقيق ذلك عن طريق تصفية البيانات التي يتم استردادها بواسطة الاستعلام ، باستخدام الفهارس ، وتقسيم الجداول الكبيرة. على الرغم من أنه ليس شيئًا يحتاجه معظم الناس (أو يكونون قادرين) على القيام به ، إلا أنه من النقاط الأساسية التي يجب وضعها في الاعتبار عند تصميم استعلامات قاعدة البيانات من البداية.

على سبيل المثال ، إذا كان استعلام قاعدة البيانات يبحث عن بيانات حول مستخدم لأغراض تسجيل الدخول ، فيجب أن يكون الاستعلام 1 LIMIT ، لأنه من الواضح أنه يجب ألا يكون هناك أكثر من بيانات مستخدم واحد مطلوبة.

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

تذكر أنه قبل اختبار السرعات بعد إجراء أي تغييرات على الوصول إلى البيانات ، يجب عليك التأكد من تعطيل التخزين المؤقت للاستعلام عن طريق تشغيل الأمر التالي:

SET SESSION query_cache_type=0;

3 - استخدام تقسيم البيانات

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

لتقسيم البيانات في قاعدة بيانات ، يمكنك اتباع الخطوات التالية:

1. عند تحديد جدول لتقسيمه ، تأكد من اختيار جدول يحتوي على كمية كبيرة من البيانات ويستفيد من التقسيم. سيساعد هذا في تحسين نظامك وتحسين أداء الاستعلام.
2. يعد اختيار طريقة التقسيم الصحيحة لقاعدة البيانات الخاصة بك أمرًا بالغ الأهمية. يمكنك الاختيار من بين النطاق أو القائمة أو التجزئة أو تقسيم المفاتيح - اعتمادًا على بنية بياناتك والاستعلامات التي تخطط لتنفيذها. تأكد من اختيار أفضل ما يناسب احتياجاتك للحصول على أداء ونتائج محسّنة.
   
   1. يعد تقسيم النطاق هو الخيار المثالي عندما يكون لديك بيانات يمكن تقسيمها إلى نطاقات معينة.على سبيل المثال ، إذا كان لديك جدول يحتوي على بيانات لعدة سنوات ، فيمكنك إنشاء قسم نطاق لتنظيمه بشكل أفضل. يمكن أن يعتمد على التاريخ أو القيمة العددية للعمود المعني.
   2. يعدتقسيم القائمة تقنية فعالة للتعامل مع البيانات التي يمكن فصلها بسهولة إلى مجموعات مختلفة وفقًا لمعامل معين.على سبيل المثال ، لديك جدول بمعلومات الموظفين مصنفة حسب القسم ؛ هذا يستلزم استخدام تقسيم القائمة.
   3. تجزئة التجزئة هي استراتيجية فعالة لترتيب البيانات في مجموعات متساوية الحجم بناءً على قيمة التجزئة لعمود معين.يسمح ذلك بالتوزيع المتساوي للبيانات عبر أقسام متعددة ، مما يجعلها خيارًا رائعًا لتوزيع البيانات بكفاءة.
   4. يشبه تقسيمالمفاتيح تقسيم التجزئة ، لكن الاختلاف الرئيسي هو أنه يستخدم قيمة عمود معينة كأساس لتقسيم البيانات إلى مجموعات مختلفة.وهذا يجعله خيارًا مثاليًا لمجموعات البيانات التي يمكن تقسيمها إلى مجموعات منفصلة بناءً على معرف فريد أو مفتاح طبيعي.
3. من خلال إنشاء جدول مقسم ، يمكنك تقسيم الجدول الأصلي بشكل فعال إلى جداول أصغر. يتم تحقيق ذلك عن طريق إضافة شرط التقسيم في عبارة CREATE TABLE ، حيث تحدد الطريقة المطلوبة وشروط التجزئة. يمكن أن يساعد القيام بذلك في تحسين أداء الاستعلام - وكذلك جعل إدارة البيانات أكثر كفاءة.
4. يمكنك نسخ البيانات بسرعة من الجدول الأصلي إلى الجدول المقسم حديثًا باستخدام عبارة INSERT INTO… SELECT. سيؤدي ذلك إلى ملء الجدول المقسم بسهولة بجميع المعلومات ذات الصلة.
5. يجب الآن إعادة تكوين التطبيقات للاستفادة من الجدول المقسم. سيحل هذا محل الجدول الأصلي ويجعل تطبيقاتك أكثر كفاءة.
6. قبل إجراء أي اختبار لتقييم تحسين الأداء المحتمل ، سيكون من الضروري تعطيل التخزين المؤقت للاستعلام أولاً عن طريق تشغيل الأمر: SET SESSION query_cache_type=0;
7. لضمان عمل الجدول المقسم بسلاسة ، من المهم مراقبة أدائه عن كثب. إذا لاحظت أي مشاكل ، فقد يساعدك تعديل شروط التقسيم أو التبديل إلى طريقة أخرى. ستساعدك المراقبة المنتظمة لأقسامك على زيادة إمكاناتها إلى أقصى حد.

ملاحظة مهمة حول ترقيات البرمجة النصية والجداول المقسمة

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

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

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

4 - ريديس

بالنسبة لعملاء Servebolt ، فإن Redis هو ملحق (مدفوع) يمكنه المساعدة في تحسين الاستعلام.

Redis (يُعرف أحيانًا باسم Remote Dictionary Server) هو حل مفتوح المصدر يخزن البيانات في الذاكرة ويمكن استخدامه للتخزين المؤقت أو قاعدة البيانات أو حتى كوسيط الرسائل. يمكن دمجها مع قاعدة بيانات لتحسين الأداء ، وتعمل كوسيط فعال بين التطبيق وقاعدة البيانات.

يعمل على تحسين الأداء وأوقات الاستجابة للتطبيقات عن طريق تقليل الحمل على قاعدة البيانات. يتم ذلك عن طريق تخزين البيانات المستخدمة بشكل متكرر في Redis بدلاً من قاعدة البيانات لكل طلب ، وبالتالي توفير وقت كبير.

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

باستخدام هذا الأسلوب ، يمكن للتطبيق الاستفادة من الوصول السريع إلى الذاكرة لـ Redis وأيضًا تخزين البيانات والوصول إليها من قاعدة البيانات حسب الحاجة.

تذكر أنك إذا كنت تستخدم Redis لأول مرة ، فستحتاج إلى تعطيل التخزين المؤقت للاستعلام قبل تشغيل أي اختبارات أداء. للقيام بذلك ، استخدم الأمر:

SET SESSION query_cache_type=0;

خاتمة

يحتوي نظام MariaDB و MySQL على مجموعة واسعة من الأدوات والأساليب لتسهيل اكتشاف الاختناقات في عمليات تنفيذ استعلام قاعدة البيانات ، مما يسمح لك بتحسين أداء تطبيقات الويب الخاصة بك.

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