تم تقديم طرق لتحسين MYSQL من عدة جوانب للحصول على الأداء. يعد التحسين مهمة معقدة لأنه يتطلب في النهاية فهم النظام بأكمله، في حين أنه من الممكن القيام ببعض التحسينات المحلية مع القليل من المعرفة بالنظام/التطبيق الخاص بك، كلما أردت أن تجعل نظامك أكثر تحسينًا، يجب أن تعرف ذلك. وأكثر من ذلك أيضًا، سيحاول هذا الفصل شرح وإعطاء بعض الأمثلة على الطرق المختلفة لتحسين MySQL، لكن تذكر أن هناك دائمًا طرق معينة (تزداد صعوبة) للقيام بذلك وهي أسرع من أجل إنشاء ملف الجزء الأكثر أهمية في جعل نظامك أسرع هو بالطبع التصميم الأساسي، كما تحتاج أيضًا إلى معرفة أن نظامك سيقوم بأشياء مثل هذه، وهذا هو عنق الزجاجة الذي تواجهه، وهي:
البحث عن القرص: الوقت الذي يستغرقه القرص للعثور على جزء من البيانات. كان متوسط الوقت الذي يستغرقه القرص الحديث المستخدم في عام 1999 أقل من 10 مللي ثانية، لذلك من الناحية النظرية يمكننا البحث عن حوالي 1000 مرة في الثانية ومن الصعب قياس تحسين جدول واحد، حيث تتمثل طريقة تحسينه في نشر البيانات على أقراص متعددة، حيث تتم قراءة/كتابة الأقراص عندما تكون في الموقع الصحيح حيث نحتاج إلى قراءة البيانات. نقل قرص واحد يشبه 10-20 ميجابايت/ثانية، ويجب أن يكون هذا أسهل للتحسين لأنه يمكنك القراءة من أقراص متعددة في دورات وحدة المعالجة المركزية المتوازية. عندما نقرأ البيانات في الذاكرة، (أو إذا كانت موجودة بالفعل) نحتاج إلى معالجتها لتحقيق ذلك نتائجنا عندما يكون هذا هو العامل المحدد الأكثر شيوعًا عندما يكون لدينا جداول ذات ذاكرة صغيرة نسبيًا، ولكن مع الجداول الصغيرة، لا يمثل عرض النطاق الترددي للذاكرة عادةً مشكلة في ذاكرة التخزين المؤقت لوحدة المعالجة المركزية، يعد هذا عنق الزجاجة غير شائع في معظم الأنظمة، لكن يجب أن تكون على دراية به 10.2 ضبط معلمات النظام/التشغيل. نبدأ بالأشياء على مستوى النظام، حيث يتم اتخاذ بعض هذه القرارات في وقت مبكر جدًا. وفي أحيان أخرى، قد تكون نظرة سريعة على هذا القسم كافية لأنه ليس مهمًا لتحقيق المكاسب الكبيرة، ولكن من الجيد دائمًا أن تشعر بمدى أهمية المكاسب على هذا المستوى وحدات المعالجة المركزية المتعددة إلى حد ما، يجب عليك استخدام Solaris (لأن الخيوط تعمل بشكل جيد حقًا) أو Linux (لأن النواة 2.2 تتمتع بدعم SMP جيد حقًا. وعلى الأجهزة 32 بت، لدى Linux حد لحجم الملف يبلغ 2G افتراضيًا). نأمل أن يتم إصلاح ذلك قريبًا عند إصدار نظام الملفات الجديد (XFS). نظرًا لأننا لا نقوم بتشغيل MySQL للإنتاج على العديد من الأنظمة الأساسية، فإننا ننصحك باختبار النظام الأساسي الذي تنوي تشغيله عليه قبل اختياره.
اقتراحات أخرى:
إذا كان لديك ذاكرة وصول عشوائي كافية، فيمكنك إزالة جميع أجهزة المبادلة، وستستخدم بعض أنظمة التشغيل جهاز SWAP في بعض الحالات حتى إذا كان لديك ذاكرة فارغة، استخدم خيار --skip -locking MySQL لتجنب القفل الخارجي وظيفة MySQL طالما أنها تعمل على خادم واحد فقط، تذكر فقط إيقاف الخادم (أو قفل الأجزاء ذات الصلة) قبل تشغيل myisamchk، ويكون هذا المفتاح إلزاميًا في بعض الأنظمة لأن القفل الخارجي غير متاح في أي عمل في جميع الحالات عند التحويل البرمجي باستخدام MIT-pthreads، يكون خيار --skip-locking افتراضيًا على وضع التشغيل (on) لأن قطيع () غير مدعوم بالكامل بواسطة MIT-pthreads على جميع الأنظمة الأساسية العميل) على نفس البيانات، فلا يمكنك استخدام --skip-locking، وإلا قم بتشغيل myisamchk على الجدول دون مسح خادم mysqld أو قفله أولاً، ولا يزال بإمكانك استخدام LOCK TABLES/UNLOCK TABLES، حتى إذا كنت تستخدم --skip -قفل.
كيف يؤثر التجميع والربط على سرعة MySQL
تم إجراء معظم الاختبارات التالية على نظام التشغيل Linux وباستخدام معيار MySQL، ولكنها يجب أن تعطي بعض المؤشرات لأنظمة التشغيل وأحمال العمل الأخرى، حيث يمكنك الحصول على أسرع الملفات التنفيذية عند الارتباط باستخدام مقابس Unix التي تتصل بقاعدة بيانات بدلاً من TCP قد يوفر /IP أيضًا أداءً أفضل في Linux، سوف تحصل على أسرع رمز عند التحويل البرمجي باستخدام pgcc و-O6. لتجميع "sql_yacc.cc" باستخدام هذه الخيارات، فإنك تتطلب حوالي 200 ميجا بايت من الذاكرة، لأن gcc/pgcc يتطلب الكثير من البيانات. الذاكرة لجعل جميع الوظائف مضمّنة عند تكوين MySQL، يجب عليك أيضًا تعيين CXX=gcc لتجنب تضمين مكتبة libstdc++ (ليست هناك حاجة إليها)، فقط باستخدام مترجم أفضل أو خيارات مترجم أفضل، يمكنك الحصول على 10 - تسريع تطبيقك بنسبة 30%، وهذا مهم بشكل خاص إذا قمت بتجميع خادم SQL بنفسك! على Intel، يجب عليك على سبيل المثال استخدام pgcc أو مترجم Cygnus CodeFusion. لقد اختبرنا مترجم Fujitsu الجديد، ولكن لم يتم ذلك بعد خالية من الأخطاء بما يكفي لتحسين تجميع MySQL.
فيما يلي بعض أوراق القياس التي قمنا بها:
إذا كنت تستخدم pgcc مع -O6 وتترجم أي شيء، فإن خادم mysqld يكون أسرع بنسبة 11% من خادم gcc (مع إصدار السلسلة 99). لا يزال بإمكانك استخدام مكتبة MySQL المرتبطة ديناميكيًا. يعد الخادم فقط أمرًا بالغ الأهمية للأداء. إذا كنت تستخدم TCP/IP بدلاً من مآخذ توصيل Unix، فستكون النتيجة أبطأ بنسبة 7.5%. على Sun SPARCstation 10، يكون gcc2.7.3 أسرع من Sun Pro C++ 4.2 أسرع بنسبة 13% في Solaris 2.5.1، يكون MIT-pthreads أبطأ بنسبة 8-12% من Solaris مع وجود سلاسل رسائل أصلية على معالج واحد، ومن المفترض أن يصبح الفرق أكبر. يتم تجميع توزيع Linux باستخدام pgcc ويتم ربطه بشكل ثابت.
كما ذكرنا سابقًا، يعد البحث عن القرص بمثابة عنق الزجاجة الكبير في الأداء، وتصبح هذه المشكلة أكثر وضوحًا عندما تبدأ البيانات في النمو، مما يجعل التخزين المؤقت مستحيلًا بالنسبة لقواعد البيانات الكبيرة، حيث يجب أن تكون عشوائيًا إلى حد ما للوصول إلى البيانات تعتمد على حقيقة أنك ستحتاج إلى قرص واحد على الأقل للقراءة والعديد من الأقراص للكتابة لتقليل هذه المشكلة، استخدم الأقراص ذات أوقات البحث المنخفضة لزيادة عدد مغازل القرص المتوفرة (وبالتالي تقليل حمل البحث). من الممكن ربط الملفات بأقراص مختلفة أو تقسيم القرص. ويعني استخدام الارتباطات الرمزية أنك تقوم بشكل رمزي بربط ملفات الفهرس/البيانات من دليل البيانات العادي إلى القرص الآخر (والذي يمكن أيضًا تقسيمه). أفضل مرات (إذا لم يتم استخدام القرص لأشياء أخرى). راجع 10.2.2.1 استخدام الارتباطات الرمزية لقواعد البيانات والجداول. يعني Split Split أن لديك العديد من الأقراص وتضع الكتلة الأولى على قرص واحد، بينما تكون الكتلة الثانية على القرص الثاني ، والكتلة n موجودة على القرص (n mod number_of_disks)، وما إلى ذلك. وهذا يعني أنه إذا كان حجم بياناتك الطبيعي أصغر من حجم الانقسام (أو مثاليًا (مرتبًا وفقًا لذلك)، فستحصل على أداء أفضل قليلاً. لاحظ أن التقسيم يعتمد بشكل كبير على نظام التشغيل وحجم الانقسام، لذا اختبر تطبيقك بأحجام تقسيم مختلفة، راجع 10.8 استخدام المعيار الخاص بك. لاحظ أن التقسيم يعتمد بشكل كبير على نظام التشغيل وحجم التقسيم ويعتمد بشكل كبير على المعلمة المعلمات وعدد الأقراص، يمكنك الحصول على أوامر من حجم الفرق، لاحظ أنه عليك اختيار تحسين الوصول العشوائي أو المتسلسل، للحصول على الموثوقية، قد ترغب في استخدام RAID 0+ 1 (تقسيم + مرآة)، ولكن في هذه الحالة، ستحتاج إلى محركي أقراص N*2 للاحتفاظ ببيانات محركات الأقراص N. إذا كان لديك المال، فمن المحتمل أن يكون هذا هو الخيار الأفضل. ومع ذلك، قد يتعين عليك أيضًا استثمار بعض برامج إدارة الحجم للتعامل معها بكفاءة الخيار الجيد هو الاحتفاظ بالبيانات الأقل أهمية (والتي يمكن إعادة إنتاجها) على قرص RAID 0، والبيانات المهمة حقًا (مثل معلومات المضيف وملفات السجل) على أقراص RAID 0+ 1 أو RAID N إذا كان لديك الكثير من عمليات الكتابة بسبب تحديث وحدات البت المتماثلة، قد يمثل RAID N مشكلة. يمكنك أيضًا تعيين معلمات لنظام الملفات الذي تستخدمه قاعدة البيانات. التغيير السهل هو تثبيت نظام الملفات باستخدام خيار noatime inode الذي يتخطى تحديثه، وهذا سوف يتجنب بعض عمليات البحث عن القرص.
يمكنك نقل الجداول وقواعد البيانات من دليل قاعدة البيانات إلى موقع آخر واستبدالها برموز ترتبط بالموقع الجديد. قد ترغب في القيام بذلك، على سبيل المثال، عن طريق نقل قاعدة بيانات إلى نظام ملفات به مساحة حرة أكبر ملاحظات MySQL: الجدول عبارة عن رابط رمزي، والذي سيحل الارتباط الرمزي ويستخدم الجدول الذي يشير إليه بالفعل. وهو يعمل على جميع الأنظمة التي تدعم استدعاء realpath() (على الأقل يدعم Linux وSolaris المسار الحقيقي()). التي لا تدعم المسار الحقيقي () على نظامك، لا ينبغي عليك الوصول إلى الجدول عبر مسار حقيقي ورابط رمزي في نفس الوقت! إذا قمت بذلك، سيكون الجدول غير متسق بعد أي تحديثات، ولا يدعم MySQL روابط قاعدة البيانات افتراضيًا، طالما لم تقم بإنشاء رابط رمزي بين قواعد البيانات، فسيعمل كل شيء بشكل جيد. افترض أن لديك قاعدة بيانات db1 في دليل بيانات MySQL، وقم بإنشاء رابط رمزي db2 يشير إلى db1:
shell&> cd /path/to/datadir
شل &> ln -s db1 db2
الآن، بالنسبة لأي جدول tbl_a في db1، سيكون هناك أيضًا جدول tbl_a في db2. إذا قام أحد الخيوط بتحديث db1.tbl_a وقام مؤشر ترابط آخر بتحديث db2.tbl_a، فستكون هناك مشكلات يجب تغيير "mysys/mf_format.c":
if (!lstat(to,&stat_buff)) /* تحقق مما إذا كان رابطًا رمزيًا */
إذا (S_ISLNK(stat_buff.st_mode) && realpath(to,buff))
قم بتغيير الكود إلى هذا:
إذا (المسار الحقيقي (إلى، برتقالي))