MySQL telah kehabisan ID yang meningkat sendiri, apakah yang perlu saya lakukan?
Sebagai seorang pengaturcara, saya tertanya-tanya adakah anda pernah menghadapi masalah seperti ini semasa temu duga kerja.
Gong Zhang ialah seorang pengaturcara Java baru-baru ini dia pergi ke sebuah syarikat Internet untuk temu duga, dan penemuduga bertanyakan soalan sedemikian kepadanya.
Sebagai contoh, integer tidak bertanda boleh menyimpan julat dari 0 hingga 4294967295, iaitu kira-kira 4.3 bilion. Apabila id yang ditambah secara automatik mencapai nilai maksimum, apakah pengecualian yang akan berlaku jika sisipan diteruskan Mari kita amalkan. Mula-mula, buat jadual tb_user, yang hanya mengandungi id kenaikan automatikPenemuduga: "Adakah anda pernah menggunakan MySQL? Adakah anda menggunakan kunci utama auto-increment atau UUID sebagai ID kunci utama dalam jadual data anda?" "Anda menggunakan kunci utama kenaikan automatik"
Penemuduga: "Mengapa kunci utama kenaikan automatik Penemuduga: "Kemudian kunci utama kenaikan automatik telah mencapai nilai maksimum. Apakah yang perlu saya lakukan? jika ia habis?" Anda boleh kembali dan menunggu pemberitahuan."
Hari ini kita akan bercakap tentang apa yang perlu dilakukan jika kunci utama yang ditambah secara automatik telah digunakan? Dalam mysql, julat jenis integer adalah seperti berikut Julat nilai int ialah: -2^31——2^31-1, iaitu, -2147483648—2147483647Seperti yang ditunjukkan dalam rajah:
create table tb_user(id int unsigned auto_increment primary key) ;
insert into tb_user values(null);
CREATE TABLE `tb_user` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8
Jika anda berhati-hati, anda akan mendapati bahawa AUTO_INCREMENT telah menjadi 2, tetapi ini jauh daripada nilai maksimum 4294967295. Untuk menjadikannya 4294967295, banyak daripada rekod mesti dimasukkan Malah, Tidak perlu menghadapi masalah sedemikian, kita boleh terus mengisytiharkan nilai awal AUTO_INCREMENT semasa membuat jadual.
Laraskan pernyataan penciptaan jadual yang baru kita buat Mula-mula padam jadual tadi, dan kemudian tambah auto_increment = 4294967295 semasa mencipta jadual
create table tb_user(id int unsigned auto_increment primary key) auto_increment = 4294967295;
Kemudian masukkan rekod ke dalam jadual juga
insert into tb_user values(null);
Begitu juga, kami menggunakan arahan show untuk melihat struktur jadual jadual tb_user:
CREATE TABLE `tb_user` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=4294967295 DEFAULT CHARSET=utf8
Melalui
select * from tb_user
kami menanyakan bahawa id ialah 4294967295, yang sudah menjadi nilai maksimum . Pada masa ini, jika
Apabila cuba memasukkan sekeping data ke dalam jadual, pengecualian konflik kunci utama dilaporkan seperti yang ditunjukkan di bawah.
[SQL]insert into tb_user values(null); [Err] 1062 - Duplicate entry '4294967295' for key 'PRIMARY'
Ini boleh menunjukkan bahawa apabila memasukkan semula, ID kenaikan automatik yang digunakan masih 4294967295, dan pengecualian konflik kunci utama akan dilaporkan.
4294967295, nombor ini sudah boleh mengatasi kebanyakan senario Jika perkhidmatan anda kerap memasukkan dan memadam data, masih ada risiko kehabisan.
Adalah disyorkan untuk menggunakan bigint unsigned, nombor ini akan menjadi besar.
Jadi, adakah penyelesaiannya adalah ya, dan penyelesaiannya adalah sangat mudah -1 hingga 2 ^63-1
-9223372036854775808 9223372036854775807
Walaupun 10,000 data dimasukkan ke dalam setiap 10,000 data untuk setiap keping data tahun, mari kita lihat berapa banyak data yang ada 10000*24*3600*365*100=31536000000000Nombor ini masih jauh daripada had atas BigInt, jadi anda boleh menyelesaikannya. masalah dengan menetapkan ID kenaikan automatik kepada jenis BigInt. Jika begini cara anda menjawab penemuduga semasa temuduga.Anda: "Ini bukan mudah. Cuma tukar jenis kunci utama autokenaikan kepada jenis BigInt." ? "
Anda: "ubah jadual tb_user tukar id id bigint;"Penemuduga: "Adakah anda mempunyai pengalaman praktikal? ;…Belum pernah mengendalikannya”Perlu diambil perhatian bahawa kaedah ini hanya disokong dalam myl5.6+ menyokong pengubahsuaian dalam talian bagi jadual pangkalan data Semasa mengubah suai jadual , untuk kebanyakan operasi, jadual asal boleh dibaca dan ditulis.
Operasi DML serentak tidak disokong untuk operasi seperti mengubah suai jenis data! Dalam erti kata lain, jika anda terus menggunakan pernyataan seperti alter untuk mengubah suai struktur data jadual dalam talian, jadual ini tidak akan dapat melaksanakan operasi kemas kini (padam, kemas kini, sisip). Oleh itu, adalah tidak mungkin untuk mengubah suai struktur jadual pada barisan pengeluaran.
Adakah cara yang lebih baik kita akan membincangkan isu ini nanti. Saya tertanya-tanya jika anda perasan situasi sedemikian Walaupun ID auto-kenaikan kunci utama bermula dari 0, iaitu julat yang boleh digunakan sekarang ialah 0~2147483647, tetapi terdapat beberapa id. nilai dalam data sebenar Ia tidak berterusan. Jika jadual pengeluaran sebenar mempunyai satu jadual dengan lebih daripada ratusan juta data, dan anda mahu menulis data pada jadual data pada masa ini, prestasi pasti akan terjejas dan anda mesti mempertimbangkan dengan cepat pemecahan pangkalan data dan jadual.Jika pangkalan data dibahagikan kepada jadual, ID yang ditambah secara automatik bagi setiap jadual tidak boleh digunakan untuk mengenal pasti data secara unik secara global. Untuk menyokong persekitaran pangkalan data sharding dan jadual sharding, kami perlu menyediakan strategi untuk menjana nombor ID unik di peringkat global.
Jadi dalam amalan, tiada cara untuk menunggu sehingga kunci utama yang ditambah secara automatik habis digunakan.
Jawapan yang lebih mesra mungkin seperti ini
Penemu bual: "Kemudian kunci utama yang ditambah secara automatik telah mencapai nilai maksimum. Apakah yang perlu saya lakukan jika ia telah digunakan?"
Anda: Saya tidak pernah mengalami masalah ini sebelum ini, kerana kami menggunakan jenis int untuk kunci utama penambahan automatik, yang secara amnya tidak dapat mencapai nilai maksimum, jadi kami perlu mempertimbangkan untuk memisahkan jadual dan pangkalan data.
Jika penemuduga terus mengejar anda dan terus bertanya kepada anda tentang perkara utama sub-pangkalan data dan sub-jadual, anda boleh menjawabnya dengan cara yang disasarkan, menunjukkan bahawa anda mempunyai pengalaman pembangunan penuh dalam kawasan ini, dan saya percaya anda boleh membantu mata Bonus untuk temu duga ini.
Atas ialah kandungan terperinci Bagaimana untuk menyelesaikan masalah apabila mysql self-increasing ID telah digunakan. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!