แนะนำให้ใช้ innodb_file_per_table หรือไม่

เรามีแอปพลิเคชั่นที่หนึ่งในตารางจะเติบโตเป็นล้านบรรทัด แต่ที่เหลือจะต่ำกว่าหนึ่งล้าน ดังนั้นอะไรคือคำแนะนำที่เราควรจะไปกับ innodb_file_per_table หรือปล่อยให้เป็น. ibd เดียว? ฉันอ่านบางบทความบอกว่าไม่ไปกับมันเพราะคุณต้องการการเข้าถึงดิสก์เพิ่มเติมเมื่อมีการเข้าร่วมที่จะดำเนินการ? เราจะได้เข้าร่วมระหว่างตารางนี้และอื่น ๆ เพื่อการสร้างรายงาน

คุณต้องไปกับinnodb_file_per_tableและคุณต้องทำความสะอาดโครงสร้างพื้นฐานของ InnoDB อย่างไร

ฉันเคยเห็นฐานข้อมูลไคลเอนต์โฮสต์ DB ติดตั้ง MySQL และปล่อยให้ InnoDB อยู่ในสถานะเริ่มต้น สิ่งนี้ทำให้พื้นที่ตารางระบบ (รู้จักกันดีในชื่อ ibdata1) ขยายตัวอย่างดุเดือด

แม้ว่าคุณจะเปลี่ยนเป็น innodb_file_per_table ไฟล์. ibd จะต้องถูกแตกจาก ibdata1 และ ibdata จะไม่ลดขนาดลง ตัวอย่างเช่นหากคุณมีตารางชื่อ mydb.mytable ที่อยู่ภายใน ibdata1 มีค่า 2GB ขึ้นไปในการแตกไฟล์คุณต้องทำสิ่งต่อไปนี้:

ขั้นตอนที่ 01) เพิ่มไปยัง /etc/my.cnf

[mysqld]
innodb_file_per_table

ขั้นตอนที่ 02) service mysql restart

ขั้นตอนที่ 03) ALTER TABLE mydb.mytable ENGINE=InnoDB;

ที่จะทำให้ไฟล์ /var/lib/mysql/mydb/mytable.ibd

น่าเสียดายที่พื้นที่ 2GB ที่ถูกครอบครองโดยตารางก่อนการเปลี่ยนแปลงไม่สามารถเรียกคืนได้ ฉันเขียนบทความที่ผ่านมาเกี่ยวกับวิธีการและทำความสะอาดโครงสร้างพื้นฐานของ InnoDB:

• เหตุใด InnoDB จึงจัดเก็บฐานข้อมูลทั้งหมดไว้ในไฟล์เดียว
• กำหนดการปรับตารางใน MySQL InnoDB ให้เหมาะสม
• ข้อผิดพลาด 1114 (HY000) ที่บรรทัด 6308 ในไฟล์ & ตาราง user_analysis เต็ม
• โพสต์ต้นฉบับของฉันใน StackOverflow

เมื่อคุณทำการเปลี่ยนแปลงที่สำคัญนี้ไม่ลืมที่จะเพิ่มinnodb_open_files (เริ่มต้น 300 บาท) มิฉะนั้นการเข้าถึงดิสก์มี จำกัด มาก

เกี่ยวกับการเข้าร่วมให้แน่ใจว่าคุณมีดัชนีที่เหมาะสมที่สนับสนุนเกณฑ์การเข้าร่วม

อัพเดท 2012-04-02 11:30 EDT

การใช้ innodb_file_per_table ในการติดตั้งใหม่ทำให้ ibdata1 เติบโตช้ามากเพราะ DDL ทั้งหมดทำภายนอกกับ ibdata คุณสามารถหดตาราง InnoDB ใด ๆ ตามที่ฉันได้กล่าวไว้ก่อนหน้านี้:

ALTER TABLE mydb.mytable ENGINE=InnoDB;

อัพเดท 2012-04-02 16:50 EDT

เมื่อพูดถึงการสำรองข้อมูลโปรดใช้ความระมัดระวังอย่างยิ่งในการทำสำเนาไฟล์. ibd ทำไม?

ภายในทุกไฟล์. ibd เป็นค่าพิเศษที่เรียกว่า tablespace_id มีรายการของค่า tablespace_id ใน ibdata1 หากคุณเคยทำการบำรุงรักษาตารางที่ต้องมีการดร็อปและสร้างตารางใหม่ tablespace_id จะแตกต่างกัน การสร้างสำเนาของไฟล์. ibd ดังกล่าวสามารถรวมกลับเข้าไปในฐานข้อมูลสำหรับการใช้งานได้หากคุณทำสำเนาของ ibdata1 ด้วย นั่นเป็นอันตรายต่อ tablespace_id ของตาราง InnoDB อื่น ๆ ทั้งหมด ในแง่นี้คุณควรทำการสำรองข้อมูล mysqldump เนื่องจาก mysqldumps เป็นสำเนาข้อมูลแบบลอจิคัล กล่าวอีกนัยหนึ่งการสำรองข้อมูลไม่ขึ้นอยู่กับระยะเวลาของ ibdata1 และคุณสามารถโหลดซ้ำได้โดยไม่มีปัญหาเรื่องความสามารถในการใช้งาน

เห็นด้วยกับ @RolandoMySQLDBA สำหรับสิ่งที่เขาไม่ได้พูดถึง: การสำรองข้อมูล

หากคุณมีระบบสำรองข้อมูล MySQL แล้วและคุณไม่ได้รวมไฟล์. ibd ไว้ในกลยุทธ์การสำรองข้อมูลระบบไฟล์ของคุณนี่ก็ไม่สำคัญ แต่ให้พิจารณาว่าการเพิ่มหนึ่งไบต์ในตาราง Innodb จะทำให้การสำรองข้อมูลเพิ่มขึ้นของตาราง. ibd ของคุณเป็นเรื่องที่ฉลาดและคุณจะเห็นว่าคุณกำลังจะหมดพื้นที่เก็บข้อมูลสำรองอย่างรวดเร็ว

ฉันมีแอปพลิเคชันที่ฉันมีสถานการณ์เช่นนี้: บางตารางที่ใหญ่และบางที่เล็กกว่า

ฉันตัดสินใจทิ้งสิ่งเล็ก ๆ ไว้ในibdata1ขณะที่วางสิ่งที่ใหญ่กว่าลงในไฟล์ของตัวเอง

ฉันทำได้โดยมีการinnodb_file_per_tableเปลี่ยนตามค่าเริ่มต้นและมีเพียงสลับออกชั่วคราวสำหรับการย้ายโต๊ะไปด้วยibdata1ALTER TABLE