Secara default, MySQL InnoDB menyimpan semua tabel dari semua DB dalam satu file global. Anda dapat mengubah ini dengan menetapkan innodb_file_per_table di konfigurasi, yang kemudian membuat satu file data untuk setiap tabel.

Saya bertanya-tanya mengapa innodb_file_per_tabletidak diaktifkan secara default. Apakah ada kerugian untuk menggunakannya?

Saya punya jawaban lengkap untuk yang ini.

Setelah innodb_file_per_table dimasukkan, dan tabel InnoDB baru dapat menyusut menggunakan ALTER TABLE <innodb-table-name> ENGINE=InnoDB';Ini akan menyusutkan .ibdfile baru DIJAMIN.

Jika Anda menjalankan ALTER TABLE <innodb-table-name> ENGINE=InnoDB';tabel InnoDB yang dibuat sebelum Anda menggunakan innodb_file_per_table, itu akan menarik data dan indeks untuk tabel itu dari file ibdata1 dan menyimpannya dalam .ibdfile, Ini akan meninggalkan seluruh merpati permanen di dalam ibdata1 yang tidak pernah dapat digunakan kembali. .

The ibdata1berkas biasanya rumah empat jenis informasi

• Tabel Data
• Indeks Tabel
• Data MVCC (Multiversioning Concurrency Control)
  • Segmen kembalikan
  • Batalkan Spasi
• Metadata Tabel (Kamus Data)
• Double Write Buffer (penulisan latar belakang untuk mencegah ketergantungan pada caching OS)
• Masukkan Buffer (mengelola perubahan pada indeks sekunder yang tidak unik)
• Lihat Pictorial Representation of ibdata1

Inilah cara yang dijamin untuk menyusutkan file ibdata1 cukup lama ...

LANGKAH 01) MySQLDump semua database menjadi file teks SQL (sebut saja SQLData.sql)

LANGKAH 02) Letakkan semua basis data (kecuali skema mysql, information_schema, dan performance_schema)

LANGKAH 03) Matikan mysql

LANGKAH 04) Tambahkan baris berikut ke /etc/my.cnf

[mysqld]
innodb_file_per_table
innodb_flush_method=O_DIRECT
innodb_log_file_size=1G
innodb_buffer_pool_size=4G
innodb_data_file_path=ibdata1:10M:autoextend

Sidenote: Apa pun yang Anda atur untuk innodb_buffer_pool_size, pastikan innodb_log_file_size adalah 25% dari innodb_buffer_pool_size.

• LANGKAH 05) Hapus ibdata1, ib_logfile0 dan ib_logfile1 ( lihat pembaruan di bawah ini sebelum menghapus! )

Pada titik ini, seharusnya hanya ada skema mysql di / var / lib / mysql

• LANGKAH 06) Mulai kembali mysql

Ini akan membuat ulang ibdata1 pada 10MB (tidak mengkonfigurasi opsi), ib_logfile0 dan ib_logfile1 masing-masing 1G

• LANGKAH 07) Muat ulang SQLData.sql ke mysql

ibdata1 akan tumbuh tetapi hanya berisi metadata tabel dan data MVCC intermiten.

Setiap tabel InnoDB akan ada di luar ibdata1

Misalkan Anda memiliki tabel InnoDB bernama mydb.mytable. Jika Anda masuk ke /var/lib/mysql/mydb, Anda akan melihat dua file yang mewakili tabel

• mytable.frm (Header Mesin Penyimpan)
• mytable.ibd(Rumah Data Tabel dan Indeks Tabel untuk mydb.mytable)

ibdata1 tidak akan lagi berisi data dan Indeks InnoDB.

Dengan opsi innodb_file_per_table di /etc/my.cnf, Anda dapat menjalankan OPTIMIZE TABLE mydb.mytableATAU ALTER TABLE mydb.mytable ENGINE=InnoDB;dan file /var/lib/mysql/mydb/mytable.ibdakan benar-benar menyusut.

Saya telah melakukan ini berkali-kali dalam karir saya sebagai DBA MySQL tanpa banyak masalah setelahnya. Bahkan, pertama kali saya melakukan ini, saya menciutkan file ibdata1 50GB menjadi 50MB.

Cobalah. Jika Anda memiliki pertanyaan lebih lanjut tentang ini, email saya. Percayalah kepadaku. Ini akan bekerja dalam jangka pendek dan jangka panjang.

UPDATE 2013-07-02 15:08 EDT

Ada peringatan yang saya miliki dalam hal ini yang saya perbarui di posting saya yang lain tetapi saya melewatkan ini: Saya memperbarui jawaban saya sedikit lagi dengan innodb_fast_shutdown karena saya digunakan untuk me-restart mysql dan menghentikan mysql untuk melakukan ini. Sekarang, satu langkah ini sangat penting karena setiap transaksi yang tidak berkomitmen dapat memiliki bagian bergerak lainnya di dalam dan di luar Log Transaksi InnoDB ( Lihat Infrastruktur InnoDB ).

Harap dicatat bahwa pengaturan innodb_fast_shutdown ke 2 akan membersihkan log juga, tetapi lebih banyak bagian yang bergerak masih ada dan dipilih pada Crash Recovery selama startup mysqld. Pengaturan 0 adalah yang terbaik.

Lihat bug .

Apakah ada kerugian untuk menggunakannya?

• lebih banyak file yang terbuka
• buka / buka kembali overhead
• File .ibd tidak menyusut (lihat 1 , 2 )

Saya selalu menggunakan innodb_file_per_table pada database besar.

innodb_file_per_table diaktifkan secara default di MariaDB.

Alasan mengapa saya memilih untuk tidak menggunakan innodb_file_per_table, adalah karena setiap tabel diletakkan di file sendiri, yang berarti setiap tabel mendapatkan sendiri, overhead terpisah (file-signature, dll.) Yang menyebabkan total, ukuran keseluruhan MySQLdirektori menjadi lebih besar daripada jika menggunakan tablespace bersama. Selain itu, ada lebih banyak ruang terbuang karena cluster-slack ketika memiliki banyak file kecil, bukan satu file besar.

Memang, biaya tambahan bukan jumlah besar dalam skema besar hal, terutama jika Anda menggunakan drive besar atau memiliki database raksasa, tetapi untuk diri saya sendiri (dan mungkin banyak "pengguna rumah"), semuanya ditambahkan dan masih terlalu banyak untuk drive kecil dengan kelompok besar di mana saya menyimpan toko MySQL saya.

Sebagai contoh, toko database saya dengan database WordPress saya dan beberapa database kecil lainnya (phpBB, dev, beberapa tes AMP, dll.), Mengonversi ke per-tabel mengubahnya dari 32MB menjadi 50MB, dan itu bahkan tidak termasuk ibdata1yang masih membutuhkan sebuah minimal 10MB , untuk total setidaknya 60MB.

Seperti yang saya katakan, ini mungkin tidak terlalu menjadi masalah bagi sebagian orang, terutama perusahaan, tetapi jika Anda adalah pengguna rumahan yang hanya meng-hosting situs, blog, dll. Maka itu memang bisa menjadi faktor dalam hal-hal seperti memilih penyedia host karena banyak host membatasi ukuran basis data Anda di samping total penggunaan disk.

Hanya untuk menambahkan sedikit info lebih lanjut

Sejak mysql 5.6.6 diaktifkan secara default

dengan innodb_file_per_table = 1, drop table bisa lebih lambat lihat Di Sini