Kesalahan 1022 - Tidak dapat menulis; kunci duplikat dalam tabel


218

Saya mendapatkan kesalahan 1022 tentang kunci duplikat pada perintah membuat tabel. Setelah melihat kueri, saya tidak bisa mengerti di mana duplikasi itu terjadi. Adakah yang bisa melihatnya?

SQL query:

-- -----------------------------------------------------
-- Table `apptwo`.`usercircle`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS  `apptwo`.`usercircle` (

 `idUserCircle` MEDIUMINT NOT NULL ,
 `userId` MEDIUMINT NULL ,
 `circleId` MEDIUMINT NULL ,
 `authUser` BINARY NULL ,
 `authOwner` BINARY NULL ,
 `startDate` DATETIME NULL ,
 `endDate` DATETIME NULL ,
PRIMARY KEY (  `idUserCircle` ) ,
INDEX  `iduser_idx` (  `userId` ASC ) ,
INDEX  `idcategory_idx` (  `circleId` ASC ) ,
CONSTRAINT  `iduser` FOREIGN KEY (  `userId` ) REFERENCES  `apptwo`.`user` (
`idUser`
) ON DELETE NO ACTION ON UPDATE NO ACTION ,
CONSTRAINT  `idcategory` FOREIGN KEY (  `circleId` ) REFERENCES  `apptwo`.`circle` (
`idCircle`
) ON DELETE NO ACTION ON UPDATE NO ACTION
) ENGINE = INNODB;

MySQL said: Documentation

#1022 - Can't write; duplicate key in table 'usercircle' 

4
Jika saya ingat dengan benar, kunci utama selalu juga merupakan INDEKS UNIK, jadi Anda harus membuang pernyataan indeks yang unik?
Mr47

1
ON DELETE NO ACTIONhanya akan menjatuhkan seluruh penggunaan kunci asing. Kecuali Anda memiliki alasan yang sangat spesifik untuk melakukan itu.
AmazingDreams

4
@AmazingDreams Mengapa? Itu masih memberlakukan integritas referensial. Hanya Anda yang harus menghapus sendiri anak-anak. Ini lebih aman daripada penghapusan bertingkat di mana Anda dapat secara tidak sengaja menghapus banyak data dengan menghapus satu kata kunci yang salah.
GolezTrol

1
stackoverflow.com/a/5810024/1567737 Mengapa menggunakan alias saat menggunakan 'alias' membuat tujuan jelas segera?
AmazingDreams

@AmazingDreams Terima kasih atas tipnya. Saya suka perdebatan di sekitarnya juga - itu membantu saya untuk belajar tentang pro dan kontra.
Git-mampu

Jawaban:


534

Kemungkinan besar Anda sudah memiliki batasan dengan nama iduseratau idcategorydalam database Anda. Ganti nama kendala jika demikian.

Kendala harus unik untuk seluruh database, bukan hanya untuk tabel spesifik yang Anda buat / ubah.

Untuk mengetahui di mana kendala saat ini digunakan, Anda dapat menggunakan pertanyaan berikut:

SELECT `TABLE_SCHEMA`, `TABLE_NAME`
FROM `information_schema`.`KEY_COLUMN_USAGE`
WHERE `CONSTRAINT_NAME` IN ('iduser', 'idcategory');

15
Persis seperti yang Anda katakan. Banyak kendala yang dihasilkan secara otomatis dengan nama iduser kategori idc yang sama di sisa dari BUAT kueri - terima kasih atas bantuan Anda!
Git-mampu

1
Saya pikir MySQL Workbench akan memperbaikinya saat mengekspor skrip pembuatan, tapi itulah yang saya dapatkan untuk "Abaikan" peringatan tentang hal semacam ini ketika saya membuka proyek.
SnowInferno

Terima kasih, sobat :) Itu sangat membantu saya dan sekarang konvensi saya untuk kunci asing berbeda dan saya tidak dapat menemukan masalah ini lagi :)

Dapat mengkonfirmasi itu. Tapi apa yang bisa saya lakukan jika kendala bernama ada meskipun tabel referensi sudah turun ?? Bisakah saya menghilangkan batasan dari tabel yang tidak ada? Saya kira saya harus memperbarui dari MySQL 5.6 ke MariaDB saat ini.
Anse

3
Terima kasih untuk ini: Kendala harus unik untuk seluruh basis data
sebasira

31

Ubah nama kunci Asing di MySQL. Anda tidak dapat memiliki nama kunci asing yang sama di tabel database.

Periksa semua tabel Anda dan semua kunci asing Anda dan hindari memiliki dua kunci asing dengan nama persis yang sama.


Itulah masalah dalam kasus saya. Saya tidak akan pernah menebaknya dan Anda menyelamatkan hari saya. Menggunakan fk_id_1, fk_id_2 dll, sekarang. Terima kasih.
JackLeEmmerdeur

15

Dari dua tautan yang Diselesaikan dengan Sukses dan Penamaan Konvensi , saya dengan mudah menyelesaikan masalah yang sama yang saya hadapi. yaitu, untuk nama kunci asing, berikan sebagai fk _colName_ TableName . Konvensi penamaan ini tidak ambigu dan juga membuat setiap ForeignKey dalam Model DB Anda unik dan Anda tidak akan pernah mendapatkan kesalahan ini.

Kesalahan 1022: Tidak bisa menulis; kunci duplikat dalam tabel


6

Seperti yang telah disebutkan orang lain, mungkin nama untuk kendala Anda sudah digunakan oleh tabel lain di DB Anda . Mereka harus unik di seluruh basis data.

Konvensi yang bagus untuk menyebutkan batasan kunci asing adalah:

fk_TableName_ColumnName

Untuk menyelidiki apakah ada kemungkinan bentrokan, Anda bisa mendaftar semua kendala yang digunakan oleh database Anda dengan pertanyaan ini:

SELECT * FROM information_schema.table_constraints WHERE constraint_schema = 'YOUR_DB';

Ketika saya menjalankan kueri ini, saya menemukan saya sebelumnya membuat salinan sementara dari sebuah tabel dan salinan ini sudah menggunakan nama kendala yang saya coba gunakan.


4

Saya hanya menghabiskan 4 jam terakhir dengan masalah yang sama. Apa yang saya lakukan adalah memastikan batasannya memiliki nama yang unik.

Anda dapat mengubah nama batasannya. Saya menambahkan nomor untuk saya sehingga saya dapat dengan mudah melacak jumlah kejadian.

Contoh

Jika batasan dalam tabel bernama boy dengan kunci asing X Batasan berikutnya dengan kunci asing X dapat disebut boy1

Saya yakin Anda akan mengetahui nama yang lebih baik daripada saya. 🙂


3

Ini juga dapat muncul sehubungan dengan bug di versi tertentu alat perubahan skema-online Percona Toolkit. Untuk bermutasi tabel besar, pt-osc pertama-tama membuat tabel duplikat dan menyalin semua catatan ke dalamnya. Dalam beberapa keadaan, beberapa versi pt-osc 2.2.x akan mencoba memberi batasan pada tabel baru nama yang sama dengan batasan pada tabel lama.

Perbaikan dirilis pada 2.3.0.

Lihat https://bugs.launchpad.net/percona-toolkit/+bug/1498128 untuk lebih jelasnya.


1

Saya juga mengalami masalah itu. Periksa apakah nama database sudah ada di Mysql, dan ganti nama yang lama.


1

Saya punya masalah ini saat membuat tabel baru. Ternyata nama Kunci Asing yang saya berikan sudah digunakan. Mengganti nama kunci memperbaikinya.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.