it-swarm.asia

أفضل ما في MyISAM و InnoDB

هل من الممكن أن تجعل InnoDB يستخدم الفهارس نفسها مثل MyISAM بدلاً من فهرس متجمع بسبب قيود RAM أثناء الاستفادة من أداء التزامن؟

17
Rick James

gen_clust_index (فهرس مجمع) تحت غطاء InnoDB يحتوي على إدخالات للمفاتيح الأساسية جنبًا إلى جنب مع Rowids. الأمر المثير للاهتمام حول استخدام gen_clust_index هو حقيقة أن أي فهارس غير فريدة تنشئها دائمًا لها صف مناظر لـ gen_clust_index لجدول. وبالتالي ، هناك دائمًا عمليات بحث في الفهرس المزدوج ، واحدة للفهرس الثانوي والأخرى لـ gen_clust_index.

تُبطل أي محاولات لتحسين تخطيط جدول أو مفتاح أساسي بسبب gen_clust_index ، أو على الأقل النتائج الهامشية في أحسن الأحوال.

مثال

يحاول بعض الأشخاص فرز MyISAM بترتيب مفتاح أساسي. وفقًا لـ تصميم قاعدة بيانات MySQL وضبطها ، الصفحة 236 الفقرة 7 ، تحت العنوان الفرعي "تخزين جدول في ترتيب الفهرس":

إذا كنت تسترد نطاقات كبيرة من البيانات المفهرسة بشكل متكرر من جدول أو فرز النتائج باستمرار على نفس مفتاح الفهرس ، فقد ترغب في التفكير في تشغيل myisamchk باستخدام خيار --sort-السجلات. القيام بذلك أخبر MySQL بفرز بيانات الجدول بنفس الترتيب الفعلي للفهرس ، ويمكن أن يساعد في تسريع هذه الأنواع من العمليات. بدلاً من ذلك ، يمكنك دمج عبارة ALTER TABLE مع ORDER BY خيار عمود معين لتحقيق نفس النتائج.

صحيح أن هذا يعمل ويعمل بشكل فعال ل MyISAM . يمكنك تنفيذ ALTER TABLE ... ORDER BY col1، col2، ...، coln ضد InnoDB حيث قد تكون الأعمدة أو لا تكون المفتاح الأساسي. لن ينتج عن ذلك نتائج أسرع لـ InnoDB لأنه ... هذا صحيح ... يجب استشارة gen_clust_index في كل مرة.

يمكن لبعض الأشخاص جعل تنسيق صف الجدول ثابتًا باستخدام ALTER TABLE mydb.mytb ROW_FORMAT=Fixed; ويمكن الحصول على زيادة بنسبة 20٪ في أداء القراءة دون أي تغييرات أخرى. هذا يعمل ويعمل بشكل فعال ل MyISAM . لن ينتج عن ذلك نتائج أسرع لـ InnoDB لأنه ... هذا صحيح ... يجب استشارة gen_clust_index في كل مرة.

يمكنك تنفيذ ما يلي على جدول InnoDB باسم mydb.mytb:

CREATE TABLE mydb.mytc LIKE mydb.mytb;
INSERT INTO mydb.mytc SELECT * FROM mydb.mytb ORDER BY col1,col2,...coln;
ALTER TABLE mydb.mytb RENAME mydb.mytd;
ALTER TABLE mydb.mytc RENAME mydb.mytb;
DROP TABLE mydb.mytd;

سيؤدي هذا إلى وضع الجدول في ترتيب الصفوف في gen_clust_index. قد ينتج عن هذا نتائج هامشية لـ InnoDB في أحسن الأحوال لأنه ... هذا صحيح ... يجب استشارة gen_clust_index في كل مرة.

الآن ، دعونا نحصل على القليل من السخرية. هناك واجهة NoSQL للاستعلام (SELECT فقط) MyISAM و InnoDB تسمى واجهة HandlerSocket (كانت تسمى سابقًا HANLDER) . يمنحك هذا الوصول إلى البيانات التي تتيح لك تجاوز كل SQL ، [~ # ~] حمض [~ # ~] ، و [~ # ~] بروتوكولات mvcc [~ # ~] . على الرغم من أنه من الممكن ، فإن IMHO WAY معقدة للغاية إلى التعليمات البرمجية والمحافظة عليها. AFAIK لا يوجد شيء في الطباعة يفيد ما إذا كانت واجهة HandlerSocket تتفاعل مع gen_clust_index أم لا.

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

14
RolandoMySQLDBA

إجابة قصيرة: لا.

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

عندما يكون لديك المفتاح المخفي المكون من 6 بايت ، تشير أي فهارس ثانوية إلى هذا المفتاح ، بدلاً من المؤشرات الدقيقة لمواقع الصف (كما هو الحال في MyISAM) ، وبذلك ينتهي بك الأمر إلى اجتياز مفتاح ثانوي ، ثم اجتياز المفتاح الأساسي للعثور على سجلاتك .


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

هذا صحيح ، ولكن عزاء واحد هو أن قواعد البيانات التجارية تحاول جعل أشجارها سمينة قدر الإمكان ، بدلاً من العمق. حاول تشغيل xtrabackup --stats على بياناتك لتراها. فمثلا:

<INDEX STATISTICS>
  table: test/table1, index: PRIMARY, space id: 12, root page 3
  estimated statistics in dictionary:
    key vals: 25265338, leaf pages 497839, size pages 498304
  real statistics:
     level 2 pages: pages=1, data=5395 bytes, data/pages=32%
     level 1 pages: pages=415, data=6471907 bytes, data/pages=95%
        leaf pages: recs=25958413, pages=497839, data=7492026403 bytes, data/pages=91%

كان هناك 497839 صفحة ورقة (~ 8 جيجابايت) ، ولكن فقط 416 صفحة أعلى (6.5 ميجابايت). لقد قمت بتشغيل هذا الأمر عدة مرات على بيانات الإنتاج ، ودائما ما يفاجئني عندما يكون لدي ملايين المليارات من السجلات ، ومستوى 1-3 صفحات فقط + صفحات أوراق.

3
Morgan Tocker

ربما يكون الفهرس العنقودي السبب في أداء التزامن InnoDB على محركات الدوران التقليدية.

يعد الوصول إلى صف من خلال الفهرس المجمع سريعًا لأن بيانات الصف موجودة في نفس الصفحة حيث يؤدي البحث في الفهرس. إذا كان الجدول كبيرًا ، فغالباً ما تحفظ بنية الفهرس المجمّع عملية إدخال/إخراج للقرص عند مقارنتها بمؤسسات التخزين التي تخزن بيانات الصف باستخدام صفحة مختلفة من سجل الفهرس. (على سبيل المثال ، يستخدم MyISAM ملفًا واحدًا لصفوف البيانات وآخر لملفات الفهرس.)

قرص الإدخال/الإخراج باهظ الثمن. لذا فإن تقليل ذلك يعد فائدة كبيرة لتحسين التوافق.

إذا بدأ القرص I/O يصبح أرخص وأقل من الاختناق (على سبيل المثال ، عندما تصبح تقنية SSD أكثر استقرارًا) ، فقد تقرر Oracle تغيير كيفية عمل فهارس InnoDB. والأرجح أنها ستبقى كما هي ، لأن نفس التقنية ستجعل "تقييد ذاكرة الوصول العشوائي" أقل مشكلة.

3
Derek Downey