REPLACE INTO ile INSERT Farkı

Veritabanı yönetiminde en sık karıştırılan konuların başında REPLACE INTO ve INSERT arasındaki fark geliyor. Özellikle production ortamında yanlış kullanılan bir REPLACE INTO sorgusu, farkında olmadan veri kaybına ya da beklenmedik davranışlara yol açabiliyor. Bu yazıda her iki yöntemi derinlemesine inceleyeceğiz, gerçek dünya senaryolarıyla ne zaman hangisini kullanmanız gerektiğini açıklayacağız.

INSERT Nedir ve Nasıl Çalışır?

INSERT, MariaDB ve MySQL’de tabloya yeni bir satır eklemek için kullanılan temel SQL komutudur. Kullanımı oldukça basittir: bir tablo belirtirsiniz, sütun isimlerini ve değerleri yazarsınız, sorgu çalışır ve yeni kayıt tabloya eklenir.

-- Temel INSERT kullanımı
INSERT INTO kullanicilar (kullanici_adi, email, kayit_tarihi)
VALUES ('ahmet_yilmaz', '[email protected]', NOW());

Peki ya aynı primary key veya unique key ile tekrar INSERT yapmaya çalışırsanız? Bu durumda MariaDB/MySQL bir hata fırlatır:

-- Duplicate key hatası örneği
ERROR 1062 (23000): Duplicate entry 'ahmet_yilmaz' for key 'kullanici_adi'

İşte bu noktada geliştiriciler genellikle iki yola başvuruyor: REPLACE INTO veya INSERT ... ON DUPLICATE KEY UPDATE. Her iki yöntemin de kendine özgü davranışları ve dikkat edilmesi gereken noktalari var.

INSERT’in Temel Kullanım Biçimleri

-- Tekli kayıt ekleme
INSERT INTO urunler (urun_adi, fiyat, stok)
VALUES ('Laptop', 15000.00, 50);

-- Çoklu kayıt ekleme (bulk insert)
INSERT INTO urunler (urun_adi, fiyat, stok)
VALUES 
    ('Mouse', 250.00, 200),
    ('Klavye', 450.00, 150),
    ('Monitor', 8500.00, 30);

-- SELECT ile birlikte INSERT (başka tablodan veri kopyalama)
INSERT INTO arsiv_siparisler (siparis_id, musteri_id, toplam, tarih)
SELECT siparis_id, musteri_id, toplam, tarih
FROM siparisler
WHERE tarih < '2023-01-01';

REPLACE INTO Nedir ve Nasıl Çalışır?

REPLACE INTO, yüzeysel bakışta INSERT‘in “akıllı” bir versiyonu gibi görünür. Kayıt yoksa ekler, varsa günceller. Kulağa harika geliyor, değil mi? Ama asıl mesele burada başlıyor.

REPLACE INTO‘nun çalışma mantığı şu şekildedir:

Eğer primary key veya unique key çakışması yoksa, INSERT gibi davranır ve yeni kaydı ekler.
Eğer bir çakışma varsa, önce mevcut kaydı siler, ardından yeni kaydı ekler.

Bu “sil ve yeniden ekle” davranışı, her şeyin yolunda göründüğü durumlarda bile ciddi sorunlara yol açabilir.

-- REPLACE INTO temel kullanımı
REPLACE INTO kullanici_profilleri (kullanici_id, bio, sehir, guncelleme_tarihi)
VALUES (42, 'Yazılım geliştirici', 'İstanbul', NOW());

Yukarıdaki sorgu ilk çalıştığında normal bir INSERT gibi çalışır. İkinci çalıştırmada ise kullanici_id = 42 olan mevcut satırı siler ve yeni bir satır oluşturur. Bu silme işlemi sırasında belirtmediğiniz tüm sütunlar varsayılan değerlerine döner.

REPLACE INTO’nun Tehlikeli Tarafı: Gizli Veri Kaybı

Bunu somut bir örnekle gösterelim:

-- Önce tablomuzun yapısına bakalım
CREATE TABLE kullanici_profilleri (
    kullanici_id INT PRIMARY KEY,
    kullanici_adi VARCHAR(50),
    bio TEXT,
    sehir VARCHAR(100),
    puan INT DEFAULT 0,
    olusturma_tarihi DATETIME DEFAULT NOW(),
    guncelleme_tarihi DATETIME
);

-- İlk kayıt ekleniyor
INSERT INTO kullanici_profilleri 
    (kullanici_id, kullanici_adi, bio, sehir, puan, olusturma_tarihi)
VALUES 
    (42, 'ahmet_yilmaz', 'Yazılım geliştirici', 'İstanbul', 1500, '2023-01-15 10:00:00');

-- Şimdi sadece bio ve sehri güncellemek istiyoruz
REPLACE INTO kullanici_profilleri 
    (kullanici_id, bio, sehir, guncelleme_tarihi)
VALUES 
    (42, 'Senior Yazılım Geliştirici', 'Ankara', NOW());

Bu sorgunun ardından kullanici_id = 42 olan kayda bakarsanız şunu görürsünüz:

kullanici_adi artık NULL
puan artık 0 (default değer)
olusturma_tarihi artık NOW() (kayıt oluşturma tarihi kayboldu)

İşte bu yüzden REPLACE INTO kullanırken çok dikkatli olmak gerekir. Kullanıcının biriktirdiği 1500 puanı bir REPLACE INTO sorgusuyla sıfırlandı ve bu durumu fark etmek bazen günler alabilir.

INSERT … ON DUPLICATE KEY UPDATE: Gerçek Anlamda Güncelleme

Çoğu zaman REPLACE INTO yerine tercih etmeniz gereken yöntem INSERT ... ON DUPLICATE KEY UPDATE‘dir. Bu yöntem gerçekten güncelleme yapar, kaydı silip yeniden oluşturmaz.

-- INSERT ... ON DUPLICATE KEY UPDATE kullanımı
INSERT INTO kullanici_profilleri 
    (kullanici_id, kullanici_adi, bio, sehir, guncelleme_tarihi)
VALUES 
    (42, 'ahmet_yilmaz', 'Senior Yazılım Geliştirici', 'Ankara', NOW())
ON DUPLICATE KEY UPDATE
    bio = VALUES(bio),
    sehir = VALUES(sehir),
    guncelleme_tarihi = VALUES(guncelleme_tarihi);

Bu sorgu çalıştığında, kullanici_id = 42 zaten varsa yalnızca bio, sehir ve guncelleme_tarihi sütunları güncellenir. puan, olusturma_tarihi ve diğer sütunlar olduğu gibi kalır. İşte gerçek anlamda “varsa güncelle, yoksa ekle” davranışı budur.

Gerçek Dünya Senaryosu: Sayaç Tablosu

E-ticaret sitelerinde ürün görüntülenme sayılarını takip eden bir tablo düşünelim:

-- Ürün istatistikleri tablosu
CREATE TABLE urun_istatistikleri (
    urun_id INT PRIMARY KEY,
    goruntuleme_sayisi INT DEFAULT 0,
    sepete_ekleme INT DEFAULT 0,
    satin_alma INT DEFAULT 0,
    son_goruntuleme DATETIME,
    FOREIGN KEY (urun_id) REFERENCES urunler(urun_id)
);

-- Doğru yöntem: ON DUPLICATE KEY UPDATE ile sayaç artırma
INSERT INTO urun_istatistikleri 
    (urun_id, goruntuleme_sayisi, son_goruntuleme)
VALUES 
    (101, 1, NOW())
ON DUPLICATE KEY UPDATE
    goruntuleme_sayisi = goruntuleme_sayisi + 1,
    son_goruntuleme = NOW();

Bu sorgu, ürün ilk kez görüntülendiğinde yeni bir kayıt oluşturur. Sonraki görüntülemelerde ise mevcut goruntuleme_sayisi değerini 1 artırır. REPLACE INTO ile bunu yapmaya çalışsaydık, her seferinde goruntuleme_sayisi sıfırlanırdı.

Ne Zaman REPLACE INTO Kullanılmalı?

REPLACE INTO‘nun tamamen kötü olduğunu söylemek doğru olmaz. Bazı spesifik durumlarda oldukça kullanışlıdır.

Tüm sütunları her zaman tam olarak belirttiğiniz durumlar için uygundur. Eğer tablodaki tüm sütunları her sorguda belirtiyorsanız ve kaydın tamamen yenilenmesini istiyorsanız, REPLACE INTO gayet işlevseldir.

Önbellek veya oturum tabloları için idealdir. Oturum verileri ya da önbellek kayıtları gibi durumlarda, kaydın tamamen taze bir şekilde yazılması istenir. Bu tür tablolarda “eski veriyi koru” gibi bir ihtiyaç yoktur.

Basit anahtar-değer yapıları için kullanılabilir. Primary key ve bir değer sütunundan oluşan basit tablolarda güvenle kullanılabilir.

-- Uygulama ayarları tablosu (anahtar-değer yapısı)
CREATE TABLE uygulama_ayarlari (
    ayar_adi VARCHAR(100) PRIMARY KEY,
    ayar_degeri TEXT,
    guncelleme_tarihi DATETIME DEFAULT NOW()
);

-- Bu tür tablolarda REPLACE INTO güvenle kullanılabilir
REPLACE INTO uygulama_ayarlari (ayar_adi, ayar_degeri, guncelleme_tarihi)
VALUES ('max_upload_size', '10MB', NOW());

REPLACE INTO uygulama_ayarlari (ayar_adi, ayar_degeri, guncelleme_tarihi)
VALUES ('maintenance_mode', 'false', NOW());

AUTO_INCREMENT ve REPLACE INTO İlişkisi

REPLACE INTO‘nun silip yeniden ekleme davranışı, AUTO_INCREMENT sütunları olan tablolarda ciddi bir soruna yol açar: AUTO_INCREMENT değeri her REPLACE işleminde artar.

-- Bunu test etmek için basit bir örnek
CREATE TABLE test_tablo (
    id INT AUTO_INCREMENT PRIMARY KEY,
    referans_kod VARCHAR(50) UNIQUE,
    deger INT
);

INSERT INTO test_tablo (referans_kod, deger) VALUES ('REF001', 100);
-- id = 1 atandı

REPLACE INTO test_tablo (referans_kod, deger) VALUES ('REF001', 200);
-- Mevcut kayıt silindi, yeni kayıt eklendi, id = 2 atandı!

REPLACE INTO test_tablo (referans_kod, deger) VALUES ('REF001', 300);
-- Yine silme ve ekleme, id = 3 atandı!

SELECT * FROM test_tablo;
-- Sonuç: id=3, referans_kod='REF001', deger=300
-- id değerleri 1 ve 2 kayboldu, bir daha kullanılmayacak

Bu durum, id değerlerinin dış sistemlerde referans olarak tutulduğu senaryolarda veri bütünlüğü sorunlarına neden olabilir. Foreign key referansları da bu silme işleminden etkilenir ve CASCADE ayarlarına bağlı olarak beklenmedik veri kayıpları yaşanabilir.

Performans Karşılaştırması

Performans açısından değerlendirildiğinde, REPLACE INTO her zaman en az iki işlem gerçekleştirir: bir DELETE ve bir INSERT. Bu nedenle:

Index güncellemeleri iki kez gerçekleşir.
Binary log’a iki ayrı event yazılır.
Trigger’lar (BEFORE DELETE, AFTER DELETE, BEFORE INSERT, AFTER INSERT) varsa hepsi tetiklenir.

INSERT ... ON DUPLICATE KEY UPDATE ise tek bir işlem olarak çalışır. Bu da onu özellikle yüksek trafikli tablolarda çok daha verimli kılar.

-- Toplu veri yükleme senaryosunda performans farkı
-- Günlük log özeti tablosu

CREATE TABLE gunluk_log_ozeti (
    tarih DATE,
    kaynak VARCHAR(50),
    hata_sayisi INT DEFAULT 0,
    uyari_sayisi INT DEFAULT 0,
    bilgi_sayisi INT DEFAULT 0,
    PRIMARY KEY (tarih, kaynak)
);

-- ON DUPLICATE KEY UPDATE ile toplu güncelleme
INSERT INTO gunluk_log_ozeti 
    (tarih, kaynak, hata_sayisi, uyari_sayisi, bilgi_sayisi)
VALUES 
    ('2024-01-15', 'web_server', 5, 23, 1250),
    ('2024-01-15', 'db_server', 0, 8, 890),
    ('2024-01-15', 'cache_server', 1, 3, 456)
ON DUPLICATE KEY UPDATE
    hata_sayisi = hata_sayisi + VALUES(hata_sayisi),
    uyari_sayisi = uyari_sayisi + VALUES(uyari_sayisi),
    bilgi_sayisi = bilgi_sayisi + VALUES(bilgi_sayisi);

Trigger Davranışı Farkı

Bu konu pek bilinmez ama REPLACE INTO, trigger’lar söz konusu olduğunda beklenmedik davranışlar üretebilir. Tablonuzda DELETE ve INSERT trigger’larınız varsa, her REPLACE INTO çalışmasında bu trigger’ların hepsi tetiklenir.

-- Audit log tablosu ve trigger örneği
CREATE TABLE kullanici_audit (
    audit_id INT AUTO_INCREMENT PRIMARY KEY,
    kullanici_id INT,
    islem_tipi ENUM('INSERT', 'UPDATE', 'DELETE'),
    islem_zamani DATETIME DEFAULT NOW()
);

-- Eğer tabloda bu trigger varsa
DELIMITER //
CREATE TRIGGER kullanici_after_delete
AFTER DELETE ON kullanicilar
FOR EACH ROW
BEGIN
    INSERT INTO kullanici_audit (kullanici_id, islem_tipi)
    VALUES (OLD.kullanici_id, 'DELETE');
END//
DELIMITER ;

-- REPLACE INTO kullandığınızda beklenmedik audit kayıtları oluşur
-- Bir "güncelleme" işlemi için hem DELETE hem INSERT audit logu yazılır

Bu durum, audit log sistemleri için ciddi bir sorun teşkil eder. Güncelleme olarak düşündüğünüz bir işlem, audit tablonuzda önce bir DELETE sonra bir INSERT olarak görünür.

Replication Ortamlarında Dikkat Edilmesi Gerekenler

MariaDB veya MySQL replication kurulumlarında REPLACE INTO kullanımı özellikle dikkat gerektirir. Statement-based replication’da REPLACE INTO sorgusu slave sunuculara aynen iletilir ve orada da DELETE + INSERT şeklinde çalışır. Bu, replication lag’ını artırabilir.

Row-based replication’da ise durum farklıdır; sunucu DELETE ve INSERT olaylarını ayrı ayrı loglar. Bu da binary log boyutunu gereksiz yere şişirebilir.

-- Replication modunu kontrol etmek
SHOW VARIABLES LIKE 'binlog_format';

-- Binary log boyutunu izlemek
SHOW BINARY LOGS;

-- REPLACE INTO yerine ON DUPLICATE KEY UPDATE kullanmak
-- replication performansını olumlu etkiler
SHOW STATUS LIKE 'Com_replace';
SHOW STATUS LIKE 'Com_insert';

INSERT IGNORE: Üçüncü Bir Seçenek

Bazen duplicate key hatasını görmezden gelmek ve sadece yeni kayıtları eklemek isteyebilirsiniz. Bu durumda INSERT IGNORE devreye girer.

-- INSERT IGNORE örneği
-- Duplicate key varsa hata vermez, sadece o kaydı atlar
INSERT IGNORE INTO abonelikler (kullanici_id, kategori_id, baslangic_tarihi)
VALUES 
    (101, 5, NOW()),
    (102, 5, NOW()),
    (101, 5, NOW());  -- kullanici_id=101 zaten varsa bu satır atlanır

-- Kaç kaydın başarıyla eklendiğini görmek için
SELECT ROW_COUNT();

INSERT IGNORE ile REPLACE INTO arasındaki temel fark şudur: INSERT IGNORE mevcut kaydı değiştirmez, sadece çakışan yeni kaydı atlar. REPLACE INTO ise mevcut kaydı siler ve yeni kaydı ekler.

Hangi Yöntemi Seçmeli: Karar Rehberi

Doğru yöntemi seçmek için kendinize şu soruları sormanız yeterlidir:

INSERT kullanın:

Yalnızca yeni kayıt ekliyorsanız ve duplicate olma ihtimali yoksa.
Duplicate olduğunda hata almak ve uygulamada ele almak istiyorsanız.

INSERT IGNORE kullanın:

Duplicate olabilecek kayıtları eklerken hata almak istemiyorsanız.
Mevcut kayıtların değişmemesini istiyorsanız.

INSERT … ON DUPLICATE KEY UPDATE kullanın:

Kayıt varsa bazı sütunları güncellemek, yoksa eklemek istiyorsanız.
Sayaç artırma gibi mevcut değere dayalı güncellemeler yapıyorsanız.
Mevcut kaydın kısmen korunması gerekiyorsanız.

REPLACE INTO kullanın:

Tablodaki tüm sütunları her sorguda belirtebiliyorsanız.
Kaydın tamamen yenilenmesi (tüm sütunlar dahil) isteniyor ve bu kasıtlıysa.
AUTO_INCREMENT büyümesi ve trigger tetiklenmeleri sorun teşkil etmiyorsa.
Basit anahtar-değer tablolarında çalışıyorsanız.

Sonuç

REPLACE INTO ve INSERT arasındaki farkı anlamak, MariaDB ve MySQL ile çalışan her sysadmin ve geliştirici için temel bir bilgidir. Pek çok ekip, REPLACE INTO‘nun basit ve pratik görünümüne kapılarak onu “akıllı güncelleme” aracı olarak kullanıyor. Oysa bu komutun silip yeniden oluşturma davranışı, fark edilmesi zor veri kayıplarına kapı aralıyor.

Production ortamlarında karşılaştığım vakaların büyük çoğunluğunda, REPLACE INTO kaynaklı sorunlar şu iki biçimde kendini gösteriyor: ya sütun değerleri beklenmedik şekilde sıfırlanıyor ya da AUTO_INCREMENT değerleri aşırı hızlı tükeniyor. Her iki durum da özellikle yüksek trafikli sistemlerde ciddi baş ağrısına dönüşüyor.

Genel tavsiyem şu: Varsayılan seçeneğiniz her zaman INSERT ... ON DUPLICATE KEY UPDATE olsun. Bu yöntem daha güvenli, daha öngörülebilir ve çoğu senaryoda daha performanslıdır. REPLACE INTO‘yu yalnızca tablonun tüm sütunlarını kontrol ettiğiniz ve kaydın tamamen yenilenmesinin kasıtlı bir davranış olduğu durumlarda kullanın. Bunun dışında, özellikle karmaşık tablolarda veya foreign key ilişkilerinin bulunduğu yapılarda, REPLACE INTO‘dan uzak durmak en güvenli yol olacaktır.

MariaDB ve MySQL’de REPLACE INTO Kullanımı ve INSERT Farkı