MySQL Duplicate Entry 1062: İçe Aktarmada Çakışan Kayıtlar

SQL içe aktarırken ERROR 1062: Duplicate entry gördüğünüzde MySQL, bir PRIMARY veya UNIQUE anahtarın tekrarına izin vermediğini söylüyordur. Bu, dosyanın tamamında aynı satırın iki kez bulunduğu anlamına gelmez. Önceki aktarım denemesinden kalan kayıt, başka bir kullanıcıya ait aynı e-posta veya değişen karşılaştırma kuralı da aynı hatayı üretebilir.

İlk yapılacak iş hata mesajındaki anahtar adını okumaktır. Çakışan değer bir kimlik numarasıysa PRIMARY ihtimali yüksektir; e-posta veya slug gibi bir değer görünüyorsa ilgili UNIQUE indeksi inceleyin. Hata almamak için anahtarı kaldırmak, verinin uygulama açısından doğru olduğunu sağlamaz.

Hangi anahtarın çakıştığını bulun

Aşağıdaki sorgularda kullanicilar kendi tablo adınızla değiştirilmelidir. Tablo yapısı, görünürde aynı olmayan hangi alanların birlikte benzersiz tutulduğunu da gösterir. Birleşik indekste yalnızca tek sütuna bakarak karar vermeyin.

SHOW CREATE TABLE kullanicilar;
SHOW INDEX FROM kullanicilar;
SELECT id, email FROM kullanicilar WHERE id = 15;
SELECT id, email FROM kullanicilar WHERE email = 'ornek@example.test';

Mevcut kaydı SQL dosyasındaki aday kayıtla karşılaştırın. Kimlik aynı ama içerik farklıysa “zaten eklenmiş” demek yanlış olabilir. Aynı e-posta farklı kimlikle geliyorsa da kimlikleri rastgele değiştirmek yerine hangi hesabın korunacağını ve ona bağlı kayıtları planlamak gerekir.

Hatanın küçük bir örneği

Aşağıdaki örnek yalnızca ayrı test oturumunda çalıştırılmalıdır. Geçici tablonun e-posta alanında büyük-küçük harfe duyarsız bir karşılaştırma kuralı vardır. Son INSERT, kimlik farklı olmasına rağmen 1062 üretir; çünkü iki e-posta bu kurala göre eşittir.

CREATE TEMPORARY TABLE aktarim_ornek (
  id INT PRIMARY KEY,
  email VARCHAR(190) CHARACTER SET utf8mb4
    COLLATE utf8mb4_unicode_ci NOT NULL,
  UNIQUE KEY uq_email (email)
) ENGINE=InnoDB;
INSERT INTO aktarim_ornek VALUES (1, 'ali@example.test');
INSERT INTO aktarim_ornek VALUES (2, 'ALI@example.test');

Bu deney “veritabanı bozuk” demek yerine hangi eşitlik kuralının çalıştığını gösterir. Kaynak ile hedefin collation değerleri farklıysa kaynaktaki benzersizlik hedefe taşınmayabilir. Böyle bir taşıma yapıyorsanız collation uyumluluğu kontrolünü de uygulayın.

Önceki deneme yarıda kaldıysa

İçe aktarma zaman aşımına uğradığında daha önceki INSERT işlemleri commit edilmiş olabilir. Aynı dosyayı yeniden başlatmanız, ilk başarılı kayıtlarla çakışmasına neden olur. Dökümde DDL bulunması da “transaction vardı, her şey geri alınmıştır” varsayımını güvensiz hâle getirir.

Hedef yalnızca bu iş için açılmış test veritabanıysa yeni ve boş bir test alanında başlamak daha anlaşılırdır. Hedef canlı veritabanıysa tabloları boşaltmayın. Önce yedek, aktarım günlükleri ve mevcut kayıtların karşılaştırması gerekir. Büyük SQL dosyası aktarımındaki katman kontrolleri, asıl kesintinin nedenini bulmaya yardımcı olur.

Mevcut veriyle birleştirme için staging alanı

İki dolu veritabanını birleştirmek, boş alana yedek geri yüklemekten farklıdır. Ayrı bir staging tablosu, aday kayıtları canlı tabloya yazmadan incelemenizi sağlar. Kaynak satır numarasını veya aktarım kimliğini koruyun; çakışan kaynak kimliğini staging tablosunun benzersiz anahtarı yapmayın.

Aşağıdaki sorgular, aktarim_adaylari tablosunda kaynak_id ve email alanları bulunduğunu varsayar. Aday e-posta alanının karşılaştırma kuralını hedeftekiyle eşleştirin. Birinci sorgu adayların kendi arasındaki tekrarları, ikinci sorgu hedefteki çakışmaları gösterir.

SELECT email, COUNT(*) AS adet
FROM aktarim_adaylari
GROUP BY email
HAVING COUNT(*) > 1;

SELECT a.kaynak_id, a.email, k.id AS hedef_id
FROM aktarim_adaylari AS a
JOIN kullanicilar AS k
  ON k.id = a.kaynak_id OR k.email = a.email;

İkinci sorguda bir adayın birden fazla hedefle eşleşmesi özellikle önemlidir: kimlik bir hesabı, e-posta başka hesabı gösteriyor olabilir. Hemen UPDATE üretmek yerine bu satırları ayrı inceleyin. Kimlikler yeniden eşlenecekse sipariş, yorum ve yetki tablolarındaki ilişkileri aynı eşleme üzerinden taşıyın.

Hata gizleyen üç kestirme

• INSERT IGNORE: Bazı hataları uyarıya indirip satırın atlanmasına veya değerin uyarlanmasına yol açabilir. İşlem bitmiş görünürken eksik kayıt oluşabilir; uyarıları ve etkilenen satırları incelemeden başarı saymayın.
• REPLACE: Basit bir UPDATE değildir. Çakışan eski satırın silinmesi ve yenisinin eklenmesi mantığı, ilişkileri ve tetikleyicileri etkileyebilir.
• ON DUPLICATE KEY UPDATE: Açık bir birleştirme kuralı varsa yararlıdır; farklı kişilere ait kayıtları doğru hesap hâline getiren otomatik karar mekanizması değildir.

AUTO_INCREMENT değerini yükseltmek, dosyada açıkça yazılan çakışan kimliği veya e-posta tekrarını çözmez. WHERE NOT EXISTS kontrolü ise tek seferlik kontrollü aktarımda yardımcı olsa da eşzamanlı iki yazıcının yarışını tek başına engellemez; kalıcı benzersizlik veritabanı kısıtıyla korunmalıdır.

Aktarım kararlarını sayılarla kapatın

Her aday kayıt için eklendi, aynı kayıt olduğu doğrulandı, güncellendi veya incelemeye ayrıldı gibi izlenebilir bir durum tutun. Atlanan kayıtları sessizce kaybetmeyin. Kaynak aday sayısı ile bu sınıfların toplamı uyuşmalı; ilişkili tablolarda sahipsiz kayıt kalmamalıdır. Ardından geri yükleme doğrulamasındaki içerik ve ilişki kontrollerini çalıştırın.

Teknik başvuru: MySQL INSERT davranışı, REPLACE ve örtük commit oluşturan komutlar.