Adakah pangkalan data secara automatik menambah kunci utama?

1 Patutkah setiap jadual mempunyai kunci utama auto-increment?

Tidak semestinya
Kekunci utama penambahan automatik boleh mempercepatkan pemasukan baris, mempunyai kelebihan dalam penggunaan ruang jadual dan menjadikan pemecahan kurang jelas.

Tetapi untuk beberapa kandungan, seperti pertanyaan berdasarkan uid yang sangat kerap dan agak tertumpu, jika anda tidak menggunakan auto-incrementing kunci utama, tetapi menggunakan uid+id sebagai kunci primer komposit, kecekapan pertanyaan akan meningkat, tetapi sisipan dan pemecahan akan Bertambah. Tetapi jika jenis penyimpanan pangkalan data adalah SSD, maka masalah ini tidak wujud.

Jadi, dalam kebanyakan kes, adalah betul untuk jadual mempunyai kunci utama autoincrementing.

2 Adakah perniagaan kunci utama yang ditambah secara automatik unik?

Tidak semestinya

Di bawah struktur meja tunggal, ya.

Dalam kes berbilang jadual, tidak semestinya strategi tertentu diperlukan, seperti menetapkan akhiran yang berbeza, selang yang sama, dsb.

3 Bolehkah kunci utama yang meningkat sendiri menjejaskan perniagaan?

Ini tidak disyorkan.

Contohnya: jadual boleh mempunyai kunci utama auto-naik, yang unik dalam jadual. Apabila membuat pertanyaan dan mengemas kini berdasarkan id, operasi boleh dipermudahkan. Tetapi secara amnya, apabila terdapat hubungan dengan perniagaan dan keunikan diperlukan, perniagaan harus mengekalkannya secara bebas, seperti menggunakan format atau algoritma, penjanaan cincang, dsb.

4 Bagaimana untuk mengekalkan keunikan kunci utama yang diselenggara oleh perniagaan dalam kes berbilang jadual?

Kekalkan segmen selang kunci kenaikan automatik, pelayan mengambil satu segmen setiap kali, dan kunci optimistik dikemas kini. Ini memerlukan jadual atau strategi tambahan untuk mengekalkan medan ini.

Berdasarkan algoritma A, awalan masa tetap, seperti: yyyyMMddHHmmss + nilai mod nombor jadual + nombor rawak, mengurangkan kemungkinan konflik dengan menambah bilangan digit. Terdapat kekangan unik pada medan jadual (tetapi kadangkala kekangan ini tidak boleh dipercayai Jika pengecualian nilai medan pendua dilemparkan semasa sisipan, sisipan akan dijana semula).

Berdasarkan algoritma B, awalan masa tetap, seperti: yyyyMMddHHmmss+nombor digit tetap, nilai kenaikan automatik perlanggaran N+nombor rawak. Tidak perlu menambah bilangan bit untuk mengurangkan kemungkinan konflik. Apabila sisipan melemparkan pengecualian nilai medan pendua, N++, disisipkan semula sehingga tiada lagi konflik. Mulai sekarang, N digunakan sebagai infiks, dan N dicache dalam pelayan ini akan terus digunakan selepas dimulakan semula. Jika pengecualian berulang berlaku, lakukan sahaja operasi yang sama dengan N++ sekali lagi. Tidak perlu menyebut nilai mod N dengan sengaja.

Berdasarkan pengurusan infix, iaitu, melaporkan infix ke pelayan pusat Dapat difahami bahawa hubungan ID pelayan dicache di suatu tempat, dan infix diperuntukkan secara dinamik.

Terdapat banyak kaedah lain, tetapi ia tidak pernah digunakan sebelum ini, jadi saya tidak akan menerangkan secara terperinci.
Algoritma B adalah mudah, mempunyai komunikasi yang kurang, dan mempunyai bilangan perlanggaran yang terhad. Algoritma A, terdapat bilangan perlanggaran yang tidak terhingga, walaupun peratusannya sangat, sangat rendah. Tetapi dalam kes konkurensi tinggi, algoritma B akan menjadi lebih ganas daripada algoritma A semasa permulaan.

Segmen selang dan pengurusan infiks kedua-duanya memperkenalkan konsep nod pusat, yang sangat bergantung tetapi boleh dipercayai dan merupakan kaedah pelaksanaan yang lebih biasa dalam industri.

Atas ialah kandungan terperinci Adakah pangkalan data secara automatik menambah kunci utama?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!