สุดยอด MyISAM และ InnoDB

เป็นไปได้หรือไม่ที่จะทำให้ InnoDB ใช้ดัชนีเช่นเดียวกับ MyISAM แทนที่จะเป็นดัชนีแบบคลัสเตอร์เนื่องจากข้อ จำกัด ของ RAM ในขณะที่รับประโยชน์จากประสิทธิภาพการทำงานพร้อมกัน?

gen_clust_index (คลัสเตอร์ดัชนี) ภายใต้ประทุนของ InnoDB บ้านเรือนรายการของคีย์หลักพร้อมกับ rowids สิ่งที่น่าสนใจเกี่ยวกับการใช้ gen_clust_index คือข้อเท็จจริงที่ว่าดัชนีที่ไม่ซ้ำกันใด ๆ ที่คุณสร้างจะมีแถวที่สอดคล้องกันสำหรับ gen_clust_index ของตารางเสมอ ดังนั้นจึงมีการค้นหาดัชนีสองครั้งเสมอหนึ่งรายการสำหรับดัชนีรองและอีกรายการหนึ่งสำหรับ gen_clust_index

ความพยายามใด ๆ ในการปรับปรุงเค้าโครงของตารางหรือคีย์หลักจะถูกทำให้ไร้ผลเนื่องจาก gen_clust_index หรืออย่างน้อยก็ควรได้รับผลลัพธ์ที่ดีที่สุด

ตัวอย่าง

บางคนพยายามเรียงลำดับ MyISAM ตามลำดับ KEY KEY ตามการออกแบบและการปรับฐานข้อมูล MySQL, หน้า 236 ย่อหน้า 7, ภายใต้หัวข้อย่อย "การจัดเก็บตารางตามลำดับดัชนี":

หากคุณดึงข้อมูลดัชนีจำนวนมากจากตารางบ่อยครั้งหรือเรียงลำดับผลลัพธ์อย่างสม่ำเสมอบนคีย์ดัชนีเดียวกันคุณอาจต้องการพิจารณาเรียกใช้ myisamchk ด้วยตัวเลือก --sort-records การทำเช่นนี้บอกให้ MySQL เรียงลำดับข้อมูลของตารางตามลำดับทางกายภาพเดียวกับดัชนีและสามารถช่วยให้การดำเนินการเหล่านี้เร็วขึ้น หรือคุณสามารถรวมคำสั่ง ALTER TABLE กับ ORDER BY ตัวเลือกคอลัมน์เฉพาะเพื่อให้ได้ผลลัพธ์เดียวกัน

รับงานนี้และผลงานได้อย่างมีประสิทธิภาพสำหรับ MyISAM คุณสามารถดำเนินการเปลี่ยนแปลงตาราง ... เรียงตาม 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;

สิ่งนี้จะทำให้ตารางเรียงตามลำดับ rowid ใน gen_clust_index สิ่งนี้อาจให้ผลลัพธ์ที่ดีที่สุดสำหรับ InnoDB เพราะ ... ถูกต้อง ... คุณต้องปรึกษา gen_clust_index ทุกครั้ง

ทีนี้มาเรื่องไร้สาระกันหน่อย มีอินเตอร์เฟซที่ NoSQL เพื่อแบบสอบถาม (SELECT เท่านั้น) MyISAM และ InnoDB เรียกว่าHandlerSocket (สมัยก่อนเรียก HANLDER) อินเตอร์เฟซ สิ่งนี้ช่วยให้คุณสามารถเข้าถึงข้อมูลซึ่งช่วยให้คุณข้ามโปรโตคอลSQL, ACIDและMVCCทั้งหมดได้ แม้ว่ามันจะเป็นไปได้ แต่ IMHO WAY TOO นั้นซับซ้อนกับรหัสและหลัก AFAIK ไม่มีสิ่งใดในการพิมพ์ที่ระบุว่าอินเตอร์เฟส HandlerSocket โต้ตอบกับ gen_clust_index หรือไม่

โดยสรุปมีหลายวิธีในการสกินแมว ในกรณีนี้คุณไม่สามารถจับแมวได้ (the gen_clust_index) ฉันเดาว่านี่คือเหตุผลว่าทำไม MyISAM ยังคงมีอยู่สำหรับประสิทธิภาพการอ่านความน่าเชื่อถือในการสั่งซื้อตารางการจัดรูปแบบแถวตารางและเครื่องมือที่สนับสนุน InnoDB จะจะยังคงการออกแบบรอบธรรมชาติกรดที่สอดคล้องกับมันจนบางจิตวิญญาณของผู้กล้าหาญต้องใช้รหัสที่มา InnoDB และแปลงมันเป็นสิ่งที่มีที่ดีที่สุดของทั้งสอง MyISAM และ InnoDB

ดัชนีคลัสเตอร์อาจจะเป็นเหตุผลสำหรับประสิทธิภาพการทำงานพร้อมกัน InnoDB บนไดรฟ์สปินแบบดั้งเดิม

การเข้าถึงแถวผ่านดัชนีคลัสเตอร์นั้นรวดเร็วเนื่องจากข้อมูลแถวอยู่ในหน้าเดียวกับที่การค้นหาดัชนีนำไปสู่ หากตารางมีขนาดใหญ่สถาปัตยกรรมดัชนีคลัสเตอร์มักจะบันทึกการดำเนินการของดิสก์ I / O เมื่อเปรียบเทียบกับหน่วยเก็บข้อมูลที่เก็บข้อมูลแถวโดยใช้หน้าอื่นจากบันทึกดัชนี (ตัวอย่างเช่น MyISAM ใช้หนึ่งไฟล์สำหรับแถวข้อมูลและอีกอันสำหรับเรคคอร์ดดัชนี)

ดิสก์ I / O มีราคาแพง ดังนั้นการลดลงจึงเป็นผลดีอย่างมากในการปรับปรุงการทำงานพร้อมกัน

หากดิสก์ I / O เริ่มมีราคาถูกลงและมีคอขวดน้อยลง (เช่นเมื่อเทคโนโลยี SSD มีเสถียรภาพมากขึ้น) Oracle อาจตัดสินใจเปลี่ยนวิธีการจัดทำดัชนี InnoDB มีแนวโน้มว่ามันจะยังคงเหมือนเดิมเพราะเทคโนโลยีเดียวกันจะทำให้ 'ข้อ จำกัด ของ RAM' มีปัญหาน้อยลง

คำตอบสั้น ๆ :ไม่

กลุ่ม InnoDB ผ่านคีย์หลักและในกรณีที่ไม่มีคีย์หลักมันจะเลือกดัชนีที่ไม่ซ้ำใครแรก ในกรณีที่ไม่มีดัชนีเฉพาะจะสร้างคีย์ 6 ไบต์ที่ซ่อนสำหรับการทำคลัสเตอร์

เมื่อคุณมีคีย์ 6 ไบต์ที่ซ่อนอยู่ดัชนีรองใด ๆ อ้างถึงคีย์นี้แทนที่จะเป็นพอยน์เตอร์ที่แน่นอนไปยังสถานที่แถว (เช่นใน MyISAM) ดังนั้นคุณจึงจบลงด้วยการแวะผ่านคีย์รองและจากนั้นคีย์ลัดเพื่อค้นหาเรกคอร์ดของคุณ .

เพื่อคาดการณ์เล็กน้อยจากคำถามของคุณฉันสมมติว่าคุณเป็นกังวลเกี่ยวกับความทรงจำที่พอดีกับต้นไม้เนื่องจากการค้นหาอย่างมีประสิทธิภาพรูทโหนดทั้งหมดควรอยู่ในหน่วยความจำเนื่องจากคุณต้องเดินพา ธ นี้เพื่อค้นหาหน้ากระดาษ

นี่เป็นเรื่องจริง แต่การปลอบใจอย่างหนึ่งคือฐานข้อมูลเชิงพาณิชย์พยายามทำให้ต้นไม้ของพวกเขาอ้วนที่สุดเท่าที่จะทำได้แทนที่จะลึก ลองใช้xtrabackup - เปิดข้อมูลของคุณเพื่อดู ตัวอย่างเช่น:

<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 หน้า (~ 8GB) แต่มีเพียง 416 หน้าด้านบน (6.5MB) ฉันใช้คำสั่งนี้สองสามครั้งกับข้อมูลการผลิตและมันก็ทำให้ฉันประหลาดใจเสมอเมื่อฉันมีบันทึกนับล้าน ๆ ล้านครั้งและมีเพียงระดับ 1-3 หน้า + หน้าใบไม้