Mengapa saya lebih suka ALGORITHM = COPY daripada ALGORITHM = INPLACE?

16

Sejak MySQL 5.6 memperkenalkan DDL online, ALTER TABLEperintah opsional dapat memiliki ALGORITHM=INPLACEatau ALGORITHM=COPYditentukan. The gambaran DDL secara online catatan bahwa, secara default, INPLACEyang digunakan sedapat mungkin, dan menyiratkan (tanpa pernah cukup yang menyatakan itu) bahwa INPLACEalgoritma lebih murah daripada COPYsatu.

Jadi alasan apa yang harus saya tentukan ALGORITHM=COPYpada ALTER TABLEpernyataan?

— Mark Amery
sumber

Jika Anda menggunakan COPY apa yang terjadi pada indeks di atas meja? Apakah Anda berakhir dengan indeks defragmented karena tabel baru dibuat dan diisi dari awal?

— Dave Poole

Jika COPY tidak mengisi dari awal maka meskipun itu adalah opsi yang lambat tabel yang dihasilkan mungkin berkinerja lebih baik karena indeks defrag.

— Dave Poole

@DavePoole Teori yang bagus, tapi saya curiga itu melenceng karena OPTIMIZE TABLE(yang saya percaya memiliki defragging indeks sebagai bagian besar dari tujuannya ) menggunakan ALGORITHM=INPLACEMySQL 5.7.4. Jadi saya pikir itu adalah kasus yang, ya, COPY melakukan defrag indeks, tetapi demikian jugaINPLACE (entah bagaimana), membatalkannya sebagai potensi keuntungan COPY.

— Mark Amery

2

"Tabel InnoDB dibuat sebelum MySQL 5.6 tidak mendukung ALTER TABLE ... ALGORITHM=INPLACEuntuk tabel yang menyertakan kolom temporal (DATE, DATETIME atau TIMESTAMP) dan belum dibangun kembali menggunakan ALTER TABLE ... ALGORITHM=COPY" ... Keterbatasan DDL Online

— JSapkota

10

Ya, ada beberapa kasus ketika Anda dapat menentukan COPY, tetapi itu karena alasan lain selain kinerja.

Penting untuk dipahami bahwa MySQL memperkenalkan fitur baru - Pemrosesan DLL online dalam versi 5.6. Itu tidak menghapus pemrosesan offline. Jadi ada kebutuhan untuk membedakan antara 2 mode ini:

Beberapa operasi masih berfungsi dalam mode Offline saja. Lihat Tabel 15.10, “ Ringkasan Status Online untuk Operasi DDL ” untuk daftar operasi DDL yang dapat atau tidak dapat dilakukan di tempat.
Operasi dalam mode Online dan Offline memiliki perilaku yang sedikit berbeda, sehingga Anda dapat memilih "lama" untuk alasan kompatibilitas.

Beberapa contoh (harap sarankan lebih banyak):

Tabel InnoDB dibuat sebelum MySQL 5.6 tidak mendukung ALTER TABLE ... ALGORITHM=INPLACEuntuk tabel yang menyertakan kolom temporal ( DATE, DATETIMEatau TIMESTAMP) dan belum dibangun kembali menggunakan ALTER TABLE ... ALGORITHM=COPY. Dalam hal ini, suatu ALTER TABLE ... ALGORITHM=INPLACEoperasi mengembalikan kesalahan.
ADD PRIMARY KEYklausa dalam COPY modediam-diam mengkonversi NULLke nilai default untuk tipe data itu (0 untuk INT, string kosong untuk varchar), sedangkan IN_PLACEtidak melakukan itu.

Dengan klausa ALGORITHM = COPY, operasi berhasil meskipun ada nilai NULL di kolom kunci utama; data diam-diam diubah, yang dapat menyebabkan masalah.

Alasan lain untuk memilih COPY:

Operasi yang Anda tentukan ALGORITHM = COPY atau old_alter_table = 1, untuk memaksa perilaku penyalinan tabel jika diperlukan untuk kompatibilitas mundur yang tepat dalam skenario khusus.

Meskipun manual MySQL tidak berbicara tentang skenario aktual, Anda dapat membayangkan beberapa. Misalnya pengembang bergantung pada tabel yang dikunci selama ALTER INDEXoperasi sehingga tabel hanya-baca atau sepenuhnya terkunci dan ada proses yang membaca tabel statis selama indeks dibangun kembali.

— Stoleg
sumber

1

Saya pikir orang juga cenderung bingung ALGORITHM=INPLACEdengan "ini DDL Online dan tidak akan mengunci basis data", padahal sebenarnya, mereka benar-benar ingin menggunakannya LOCK=NONE.

— Brendan Byrd

2

@Stoleg mungkin punya jawaban terbaik, tapi ini satu lagi. Ini dugaan terpelajar yang ditinggalkan pengembang =COPYsebagai pintu keluar jika ada bug serius di dalamnya =INLINE. Ini akan memungkinkan pengguna terus menggunakan ALTERbahkan jika fitur baru rusak.

Saya telah melihat hal-hal seperti ini (pada flag sql_mode,, my.cnfsetting, dll) selama bertahun-tahun. Maksud dari rilis baru ini jelas untuk menghadirkan fitur baru yang lebih baik.

Bendera optimisasi termasuk dalam kategori ini, tetapi bahkan ada lebih banyak alasan untuk bertahan pada tindakan sebelumnya - Pengoptimal akan selalu "melakukan kesalahan" kadang-kadang; ada terlalu banyak kemungkinan.

— Rick James
sumber

1

Mengapa Anda menyebutnya "escape hatch" daripada "kompatibilitas mundur"? Meskipun mungkin tidak ada banyak perbedaan;)

— Stoleg

1

Saya akan mengatakan "kompatibilitas ke belakang" jika saya memerlukan kode yang sama untuk berjalan di kedua versi. Tetapi kemudian saya akan khawatir tentang apakah sintaks baru dikenali oleh versi lama.

— Rick James

-1

Dalam versi MySQL yang mendukung enkripsi tablespace InnoDB, ketika Anda mengubah tabel untuk menambahkan enkripsi, perubahan dilakukan menggunakan algoritma salin karena kebutuhan.

— nthdesign
sumber