Mengapa panjang baris AVG 4 kali lebih besar dari yang diharapkan?

Ada banyak alasan ukuran baris rata-rata menjadi tinggi.

• Ini adalah perkiraan. (Saya telah menemukan bahwa biasanya 2x-3x tinggi.) Dalam satu kasus ekstrim -- satu baris dalam tabel -- ia akan mengklaim 16384 byte per baris. Itu adalah satu blok InnoDB. Jumlah baris dalam tabel adalah perkiraan . Ruang disk yang digunakan untuk baris sudah tepat, tetapi lihat overhead, di bawah. Ukuran baris rata-rata adalah hasil bagi dari keduanya.

• Overhead per kolom -- 1 atau 2 byte

• Overhead per baris -- 20-30 byte -- untuk menangani transaksi, menemukan baris dalam satu blok, dll

• Overhead per blok -- sejumlah byte per 16KB blok

• Overhead untuk thrashing di BTree -- min sekitar 1/16 blok, maks sekitar setengah blok, rata-rata sekitar 30% setelah banyak penghapusan dan/atau penyisipan acak.

• Overhead untuk pra-alokasi potongan ruang disk (1MB? 8MB?)

• Saat tabel tumbuh dari pemasangan di satu blok, algoritme tata letak bergeser, dan persentase overhead melonjak untuk sementara.

• Baris yang dihapus tidak mengembalikan ruangnya ke OS, sehingga ukuran file tetap konstan, sehingga meningkatkan jelas ukuran baris.

• Jika Anda tidak memiliki PRIMARY KEY yang eksplisit atau UNIQUE kunci yang dapat dipromosikan ke PK, maka ada bidang 6-byte yang tidak dapat diakses (per baris) untuk PK.

• TEXT besar /BLOB dan bahkan VARCHAR disimpan "off-record". Ini sangat menyulitkan perhitungan. Dan itu tergantung pada yang mana dari 4 ROW_FORMATs Anda menggunakan. Dalam beberapa kasus, ada "penunjuk" 20 byte untuk setiap sel tersebut.

• FOREIGN KEY kendala tidak menambah ruang yang dibutuhkan, kecuali bahwa mereka mungkin memaksa pembuatan indeks.

• INDEXes , selain PRIMARY KEY tidak termasuk dalam avg_row_length.

• PRIMARY KEY biasanya melibatkan sangat sedikit overhead dalam data Btree. Aturan Praktis sederhana adalah 1% overhead (di atas kolom itu sendiri). Overhead ini adalah node non-daun dari BTree.

• Saat transaksi InnoDB sibuk, setiap baris yang dimodifikasi disimpan di "daftar riwayat". Hal ini menyebabkan lebih banyak overhead.

• (Tidak sepenuhnya terkait). COMPRESSED dari InnoDB memiliki masalah -- ini hanya memberikan sekitar 2x kompresi, tidak seperti kompresi teks biasa 3x. Membutuhkan sedikit RAM karena harus memiliki data terkompresi dan tidak terkompresi di buffer_pool secara bersamaan (setidaknya untuk beberapa blok).

SHOW TABLE STATUS dan mengambil dari information_schema.TABLES memberikan data yang sama. Ada cara untuk mendapatkan beberapa wawasan tentang kedalaman B+Tree untuk data dan untuk setiap tabel.