เครื่องมือเพิ่มประสิทธิภาพการสืบค้น MySQL อ่านสถิติดัชนีจากที่ใด


14

ฉันพยายามหาว่าตัวเพิ่มประสิทธิภาพ MySQL ได้รับรายการดัชนีที่มีอยู่ในตารางหรือไม่เมื่อประเมินค่าแบบสอบถาม (เตรียม) แบบสอบถาม


+1 สำหรับคำถามที่ดีนี้เพราะนักพัฒนาและ DBA ควรหยุดและคิดว่าจะรวบรวมและจัดเก็บสถิติดัชนีอย่างไร
RolandoMySQLDBA

สำหรับการอ้างอิงจากเว็บไซต์เอกสาร mysql: < dev.mysql.com/doc/refman/5.0/en/innodb-restrictions.html >> ANALYZE TABLEกำหนดดัชนีความเป็นหัวใจ (ตามที่ปรากฏในคอลัมน์ Cardinality ของSHOW INDEXผลลัพธ์) โดยทำการดำน้ำแบบสุ่มแปดครั้ง ของต้นไม้ดัชนีและอัปเดตการประเมินความสำคัญเชิงดัชนีตามลำดับ เนื่องจากสิ่งเหล่านี้เป็นเพียงการประมาณการการเรียกใช้ ANALYZE TABLE ซ้ำ ๆ อาจทำให้ตัวเลขต่างกัน สิ่งนี้ทำให้ANALYZE TABLEรวดเร็วบนตาราง InnoDB แต่ไม่ถูกต้อง 100% เนื่องจากไม่คำนึงถึงแถวทั้งหมด
เฉิน Xie

คำตอบ:


6

คำตอบตรงนี้ก็คือ

information_schema.statistics

mysql> desc information_schema.statistics;
+---------------+---------------+------+-----+---------+-------+
| Field         | Type          | Null | Key | Default | Extra |
+---------------+---------------+------+-----+---------+-------+
| TABLE_CATALOG | varchar(512)  | NO   |     |         |       |
| TABLE_SCHEMA  | varchar(64)   | NO   |     |         |       |
| TABLE_NAME    | varchar(64)   | NO   |     |         |       |
| NON_UNIQUE    | bigint(1)     | NO   |     | 0       |       |
| INDEX_SCHEMA  | varchar(64)   | NO   |     |         |       |
| INDEX_NAME    | varchar(64)   | NO   |     |         |       |
| SEQ_IN_INDEX  | bigint(2)     | NO   |     | 0       |       |
| COLUMN_NAME   | varchar(64)   | NO   |     |         |       |
| COLLATION     | varchar(1)    | YES  |     | NULL    |       |
| CARDINALITY   | bigint(21)    | YES  |     | NULL    |       |
| SUB_PART      | bigint(3)     | YES  |     | NULL    |       |
| PACKED        | varchar(10)   | YES  |     | NULL    |       |
| NULLABLE      | varchar(3)    | NO   |     |         |       |
| INDEX_TYPE    | varchar(16)   | NO   |     |         |       |
| COMMENT       | varchar(16)   | YES  |     | NULL    |       |
| INDEX_COMMENT | varchar(1024) | NO   |     |         |       |
+---------------+---------------+------+-----+---------+-------+
16 rows in set (0.01 sec)

คุณสามารถเลือกจากตารางนั้นด้วย

SELECT * FROM information_schema.statistics
WHERE table_schema='mydb' AND table_name='mytable';

หรือดูสถิติโดยทำ

แสดงดัชนีจาก mydb.mytabletable

โปรดทราบว่าตารางนี้ไม่ถูกต้องเสมอในสภาพแวดล้อมที่เขียนหนัก คุณจะต้องเรียกใช้ANALYZE TABLE เป็นระยะกับตาราง MyISAM ทั้งหมดที่มีการปรับปรุงบ่อยครั้ง มิฉะนั้นเครื่องมือเพิ่มประสิทธิภาพข้อความค้นหา MySQL ซึ่งอาศัย data_schema.statistics บางครั้งสามารถสร้างทางเลือกที่ไม่ดีเมื่อพัฒนาแผนอธิบายสำหรับแบบสอบถาม สถิติดัชนีจะต้องทันสมัยที่สุดเท่าที่จะทำได้

ตารางวิเคราะห์มีผลอย่างไม่มีผลกับตาราง InnoDB สถิติดัชนีทั้งหมดสำหรับ InnoDB จะคำนวณตามความต้องการโดยการดำลงในหน้า BTREE ดังนั้นเมื่อคุณเรียกใช้ SHOW INDEXES FROM เทียบกับตาราง InnoDB ความสำคัญที่แสดงนั้นเป็นค่าประมาณเสมอ

อัพเดท 2011-06-21 12:17 EDT

สำหรับการชี้แจงตารางวิเคราะห์ให้ฉันใช้ถ้อยคำใหม่ การใช้ ANALYZE TABLE บนตาราง InnoDB นั้นไร้ประโยชน์อย่างสมบูรณ์ แม้ว่าคุณจะใช้ ANALYZE TABLE บนตาราง InnoDB แล้วเอ็นจิ้นการจัดเก็บข้อมูล InnoDB จะทำการดำดิ่งลงในดัชนีสำหรับการประมาณค่าความซ้ำซ้อนของหัวใจซ้ำแล้วซ้ำอีกทำให้สถิติที่คุณรวบรวม ในความเป็นจริง Percona ทำการทดสอบบางอย่างในตารางการวิเคราะห์และมาถึงข้อสรุปที่เช่นกัน


5

Re: ตารางวิเคราะห์มีอย่างไม่มีผลกับตาราง InnoDB

ฉันไม่แน่ใจว่าข้อความนี้เป็นจริงหรือไม่ เรามีการอ่านและเขียนตาราง innodb อย่างมากและเมื่อเครื่องมือเพิ่มประสิทธิภาพ mysql เป็นตัวเลือกที่ไม่ถูกต้องการอธิบายผลลัพธ์ของแบบสอบถามจะแสดงกลยุทธ์ที่ไม่ดี และ SHOW INDEXES จากตาราง Innodb แสดงให้เห็นถึงความแปรปรวนจำนวนมากในค่าความเป็นหัวใจของพวกเขา แต่การเรียกใช้คำสั่งวิเคราะห์บนตาราง Innodb เหล่านั้นจะแก้ไขแผนอธิบายและกำจัดพฤติกรรมความแปรปรวนของภาวะเชิงการนับ ฉันไม่ทราบว่าคำสั่งตารางวิเคราะห์คำสั่งบนตาราง Innodb ช่วยตลอดเวลาหรือไม่ แต่ในกรณีของเรามันช่วยได้ประมาณ 99%

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


ฉันปรับปรุงคำตอบของฉันเพื่อเน้นความไร้ประโยชน์ของตารางการวิเคราะห์บนตาราง InnoDB
RolandoMySQLDBA

ฉันเห็นด้วยกับคำตอบของคุณเมื่อคุณพูดถึงความแปรปรวนในภาวะเชิงการนับ นั่นคือสิ่งที่ฉันพูดเมื่อฉันพูดถึงการประมาณเชิงหัวใจ
RolandoMySQLDBA

ฉันยังต้องการพูดถึงว่าการใช้คำแนะนำในการค้นหาไม่ใช่สิ่งที่ดีที่สุดที่จะทำเมื่อ MySQL Query Optimizer มีแนวโน้มที่จะกำจัดพวกเขาตลอดเวลา นี่คือลิงค์ไปสู่สิ่งที่เกิดขึ้นภายในแบบสอบถามที่สามารถทำให้ข้อมูลหายไปในส่วนของแผนแบบสอบถาม: dba.stackexchange.com/questions/1371/ …
RolandoMySQLDBA

2

วิเคราะห์ตารางสำหรับ MyISAM สแกนทั้งตารางและสร้างสถิติใหม่ซึ่งบันทึกไว้ในไฟล์ (.II) ในไฟล์. MYI มันไม่ค่อยจำเป็น

วิเคราะห์ตารางสำหรับ InnoDB ไม่บางสิ่งบางอย่างที่ต้องทำ - มันไม่ดำน้ำดังกล่าว ปัญหาคือมันอาจช่วยทำให้สิ่งต่าง ๆ แย่ลงหรือ (เป็นไปได้มากที่สุด) จะไม่ทำให้เกิดความแตกต่างที่มองเห็นได้ (ยกเว้นในเรื่องสำคัญ)

รุ่นที่ใหม่กว่าสัญญาว่าจะอนุญาตให้เปลี่ยนโพรบที่ไม่สุ่ม 8 รายการเป็น (1) สุ่มมากขึ้น (2) ให้คุณเปลี่ยน "8" (มีข้อดีข้อเสียของสิ่งนี้!) และ (3) การบันทึกข้ามรีสตาร์ท

บรรทัดล่าง: InnoDB ยังไม่ได้รับ 'ถูกต้อง' วิเคราะห์เมื่อคุณรู้สึกชอบ แต่อย่ากลั้นลมหายใจ

ปรับปรุง

หากต้องการวลีใหม่ ... ANALYZE TABLEมีผลชั่วคราว (อาจเป็นประโยชน์อาจไม่ได้) ในการเพิ่มประสิทธิภาพของตาราง InnoDB

"รุ่นที่ใหม่กว่า": เริ่มต้นด้วย 5.6.6 (2012) และ MariaDB 10.1 (2014) สถิติได้รับการจัดการที่ดีขึ้นมากและANALYZEตอนนี้ (1) ต้องการน้อยกว่าและ (2) ถาวรมากขึ้น

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.