Ini adalah salah satu topik paling kontroversial yang pernah saya tangani selama bertahun-tahun sebagai MySQL DBA dan di DBA StackExchange.
Untuk membuatnya lebih sedikit, tidak hanya ada cara lain untuk mengecilkan ibdata1 . Dengan innodb_file_per_table dinonaktifkan, setiap kali Anda menjalankan OPTIMIZE TABLE
tabel InnoDB, ibdata1 tumbuh dengan cepat. Data yang dijatuhkan menggunakan DROP TABLE
dan DROP DATABASE
tidak dapat digulirkan kembali karena mereka DDL, bukan DML. Saya percaya Oracle dan MSSQL dapat mengembalikan DDL. MySQL tidak bisa melakukan itu.
Ada beberapa kelas informasi yang berada di ibdata1
- Tabel Data
- Indeks Tabel
- Tabel MetaData
- Data Kontrol MVCC
- Double Write Buffer (Penulisan latar belakang untuk mencegah ketergantungan pada caching OS)
- Masukkan Buffer (Mengelola perubahan pada indeks sekunder yang tidak unik)
Menggunakan innodb_file_per_table=1
akan memungkinkan Anda untuk membuat tabel baru dengan data tabel dan indeks tabel dibuat di luar ibdata1. Anda bisa mengekstrak tabel apa pun yang masih ada di dalam ibdata1 menggunakan ALTER TABLE ... ENGINE=InnoDB;
atau OPTIMIZE TABLE
tetapi itu akan meninggalkan ruang besar yang tidak terpakai yang kosong di ibdata1.
Meskipun demikian, Anda harus membersihkan infrastruktur InnoDB. Saya sudah menulis posting StackExchange tentang bagaimana dan mengapa melakukan ini:
Kabar baik
Anda hanya perlu membuang data, memuat ulang sekali lagi dan tidak pernah mengunjungi lagi masalah ini . Menjalankan OPTIMIZE TABLE
sesudahnya memang akan mengecilkan .ibd
file tablespace untuk setiap tabel InnoDB.