Cevap.

Soru Tarihi:

Veri toplu güncellemesi, veri taşımaları, göçler ve iş mantığı düzeltmeleri sırasında ihtiyaç duyulur. Tipik bir örnek: çalışma tablosundaki on milyonlarca satırın durumunu değiştirmek, hizmeti durdurmadan, erişilebilirlik ve performansı koruyarak gereklidir.

Sorun:

Sınırlama olmaksızın standart UPDATE uzun sürer, kilitlerin tırmanmasına neden olabilir, tabloyu kilitler ve hata durumunda toplu geri alma sürecine yol açar. Kullanıcılar üzerinde minimum etki sağlamak ve işlem bütünlüğü sağlamak için bir yaklaşım gereklidir.

Çözüm:

İşlemi WHERE ve LIMIT/TOP kullanarak partilere ayırmak.
Pencereli fonksiyonlar, geçici tablolar ve geçici işaretçiler kullanmak.
Bazen — geçici olarak indeksleri kaldırmak, kaydetme noktaları (SAVEPOINT) belirlemek, daha düşük bir yalıtım seviyesi kullanmak gerekebilir.

Kod örneği:

-- 10.000 satır başına parti güncelleme örneği
WHILE 1 = 1
BEGIN
  UPDATE TOP (10000) mytable
  SET status = 'archived', updated = GETDATE()
  WHERE status = 'active';
  IF @@ROWCOUNT = 0 BREAK;
END

Anahtar özellikler:

Parti işleme, kilitlerin bekletilme süresini azaltır.
Atomiklik sadece her mini işlemin kapsamı içinde garanti edilir.
Bazı veritabanı yönetim sistemlerinde, büyük miktarlarda çalışma hızlandıran özel toplu operatörler bulunmaktadır.

Tuzaklı sorular.

Tek bir işlemde toplu UPDATE yapmak ve tabloyu kilitlememek mümkün mü?

Genellikle hayır. Büyük bir işlem tablo / sayfayı kilitleyerek kilitlenme ve zaman aşımı riskini artırır. Partilerle çalışmak daha iyidir.

İndekslerin varlığı, toplu güncellemenin hızını etkiler mi?

Evet. İndekslenebilir alanların her birinin güncellenmesi, her satır için indeksin yeniden yapılandırılmasını gerektirir. Bazen indekslerin geçici olarak kaldırılması mantıklıdır, ancak bu derin bir analiz gerektirir.

Parti güncellemeleri atomik olarak tüm satırları mı günceller?

Hayır, atomiklik yalnızca bir partinin (satır/işlem sınırı) içindeki süreçle garanti edilir. Eğer parti kesilirse, bazı satırlar güncellenir, bazıları güncellenmez. Gerçek atomiklik için — tek bir işlemde tam bir UPDATE, bu da yüksek hacimlerde tehlikelidir.

Tipik hatalar ve anti-paternler

Limit olmaksızın anlık UPDATE, kilit tırmanışına neden olur.
İndeksleri dikkate almamak — indekslenebilir sütunlarda yüksek performans beklentisi.
Kaydetme noktalarının (SAVEPOINT) kullanılmaması.

Gerçek bir örnek

Olumsuz vakalar

Teknik mühendis, üretim veritabanında 10 milyon satırı tek bir sorguyla güncellemeye karar verdi: UPDATE mytable SET status = 'archived'. Site "dondu", geri alma işlemi on dakikalar sürdü, performans etkilendi.

Artılar:

Komutun basitliği, minimum kod. Eksiler:
Üretim hizmetinin donması/kilidi.
Hata durumunda büyük geri alma ihtimali.

Olumlu vakalar

Sorgu, 10.000 satırlık partilere bölünmüş, güncelleme; çalışma saatlerinde kesinti olmadan gerçekleşmiştir.