Pertama-tama, jika Anda default pada mesin penyimpanan InnoDB MySQL, maka tidak ada cara Anda dapat memperbarui data tanpa kunci baris kecuali mengatur tingkat isolasi transaksi ke READ UNCOMMITTED dengan menjalankan
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;
Namun, saya tidak berpikir perilaku basis data seperti yang Anda harapkan karena pembacaan kotor diizinkan dalam kasus ini. READ UNCOMMITTED jarang berguna dalam praktik.
Untuk melengkapi jawaban dari @Tim, memang ada baiknya untuk memiliki indeks unik pada kolom yang digunakan dalam klausa where. Namun, harap dicatat juga bahwa tidak ada jaminan mutlak bahwa pengoptimal pada akhirnya akan memilih rencana eksekusi tersebut menggunakan indeks yang dibuat. Ini mungkin berhasil atau tidak, tergantung kasusnya.
Untuk kasus Anda, yang dapat Anda lakukan adalah membagi transaksi panjang menjadi beberapa transaksi pendek. Alih-alih memperbarui jutaan baris dalam satu bidikan, memindai hanya ribuan baris setiap kali akan lebih baik. Kunci X dilepaskan ketika setiap transaksi pendek dilakukan atau dibatalkan, memberikan kesempatan kepada pembaruan serentak untuk melanjutkan.
Omong-omong, saya berasumsi bahwa batch Anda memiliki prioritas lebih rendah daripada proses online lainnya, sehingga dapat dijadwalkan di luar jam sibuk untuk meminimalkan dampaknya.
P.S. Kunci IX tidak ada dalam rekaman itu sendiri, tetapi dilampirkan ke objek tabel dengan granularitas yang lebih tinggi. Dan bahkan dengan tingkat isolasi transaksi REPEATABLE READ, tidak ada kunci celah saat kueri menggunakan indeks unik.
