Ukuran transaksi MySQL - seberapa besar terlalu besar?

Saya memiliki proses impor yang berjalan sangat sering dan saya ingin itu menjadi semacam 'semua atau tidak sama sekali' kesepakatan, alias: transaksi.

Ada banyak aspek, dan impor dapat menghasilkan di mana saja antara 100k-1mil + catatan. Ini sama dengan muatan mulai dari beberapa MB hingga beberapa ratus MB data.

Saya tahu tabel temp adalah pilihan lain - tetapi metode ini tampaknya sangat berguna.

Adakah peringatan yang harus diperhatikan tentang praktik semacam ini dengan sejumlah besar manipulasi data di antara komitmen? (Di luar dari burst penulisan / pengindeksan umum yang dilakukan setelah berkomitmen)

— es tipis
sumber

Secara pribadi, saya suka memiliki keseimbangan. Saya melakukan impor dalam transaksi 1k atau 10k, karena saya hanya tahu bahwa itu akan mencapai sekitar 900k baris dan kemudian macet karena ukuran buffer atau sesuatu yang konyol. Cukup mudah untuk mengambil dari itu, dan tidak sebanyak I / O.

— Kapten Hypertext

Satu hambatan yang harus diperhatikan adalah InnoDB Log Buffer. Ukurannya diatur oleh innodb_log_buffer_size . Inilah yang dikatakan oleh Dokumentasi MySQL tentangnya:

Ukuran dalam byte buffer yang digunakan InnoDB untuk menulis ke file log pada disk. Nilai default adalah 8MB. Buffer log yang besar memungkinkan transaksi besar berjalan tanpa perlu menulis log ke disk sebelum transaksi dilakukan. Jadi, jika Anda memiliki transaksi besar, membuat buffer log lebih besar menghemat disk I / O.

Buffer Log InnoDB tidak boleh disamakan dengan Pool Buffer InnoDB. Perbedaan utama di antara mereka adalah tujuan mereka. Buffer Log InnoDB pada dasarnya akan merekam perubahan jangka pendek yang bisa ditulis ke redo log (ib_logfile0, ib_logfile1). Pool Buffer InnoDB (berukuran oleh innodb_buffer_pool_size ) menyimpan cache data dan indeks halaman yang akan dikomit (jika halaman tersebut kotor) dan akhirnya ditulis) ke disk. Setelah dilakukan, halaman perubahan tetap dalam RAM sampai dihapus melalui aturan LRU.

Transaksi besar harus disalurkan melalui Buffer Log. Seperti yang disebutkan, buffer log yang lebih besar akan mengurangi disk I / O. Hanya komit besar yang akan memberikan hambatan.

Anda mungkin ingin melihat opsi InnoDB lain untuk dikonfigurasikan.

innodb_flush_method : Ini menentukan bagaimana flush ditangani dan apakah atau tidak untuk membiarkan OS cache menulis ke InnoDB ( Anda harus bereksperimen antara O_DSYNC dan O_DIRECT )
innodb_read_io_threads (Gunakan Maks: 64)
innodb_write_io_threads (Gunakan Maks: 64)
innodb_io_capacity (gunakan nilai yang lebih tinggi seperti 5000 atau 10000, tetapi perangkat keras akan melengkapinya untuk Anda, dengan kata lain, biarkan perangkat keras menentukan kapasitas IO setelah Anda menetapkan jumlah besar)
innodb_thread_concurrency : Nilai default adalah 0. Saya belajar langsung dari Ronald Bradford di Percona NYC 2011 untuk meninggalkan angka ini di 0. Hal ini memungkinkan InnoDB memutuskan jumlah tiket konkurensi terbaik yang bisa ditangani)

Saya punya posting lain tentang mengoptimalkan InnoDB untuk penelitian lebih lanjut

— RolandoMySQLDBA
sumber

entah bagaimana aku tahu kau akan terlibat dalam ini. Terima kasih atas jawaban menyeluruh yang sepertinya selalu Anda berikan. Pertanyaan sampingan: Apakah Anda memiliki sumber daya terkait penggunaan innodb_io_capacity? Ketika dokumentasi menunjukkan konsumen SATA 5400 / 7200RPM memiliki nilai 100, apakah strategi Anda Anda sarankan untuk 'menghapus batas' dengan menetapkan nilai itu begitu tinggi?

— Thinice

Saya biasanya mengatur innodb_io_capacity lebih tinggi dan membiarkan perangkat keras menyelesaikannya. Saya akan menambahkan ini ke jawaban saya sekarang.

— RolandoMySQLDBA