InnoDB Lock Mekanizmaları: Record, Gap ve Next-Key Locks’ın Derinlemesine İncelenmesi

Veritabanlarında eşzamanlı işlemler kaçınılmazdır. Birden fazla kullanıcı aynı anda aynı tabloya eriştiğinde, verilerin bütünlüğünü koruyabilmek için lock mekanizmaları devreye girer. InnoDB bu konuda oldukça gelişmiş bir yapıya sahiptir.

Bu yazıda, InnoDB’nin record locks, gap locks, next-key locks ve diğer özel lock türlerini örnekler üzerinden inceleyeceğiz. Ayrıca deadlock senaryosu üzerinden neler yaşanabileceğini göstereceğiz.

1. Lock’ları Nerede Görüyoruz?

InnoDB’nin oluşturduğu lock’ları izlemek için:

SELECT thread_id, event_id,
       object_schema, object_name, index_name,
       lock_type, lock_mode, lock_status, lock_data
FROM

SELECT thread_id, event_id,
       object_schema, object_name, index_name,
       lock_type, lock_mode, lock_status, lock_data
FROM

SELECT thread_id, event_id,
       object_schema, object_name, index_name,
       lock_type, lock_mode, lock_status, lock_data
FROM

Bu sorgunun oluşturduğu lockları bir inceleyelim. Örneğin şu sorguyu çalıştırdığımızda:

UPDATE world.city
SET CountryCode = 'LX'
WHERE CountryCode = 'LUX';

UPDATE world.city
SET CountryCode = 'LX'
WHERE CountryCode = 'LUX';

UPDATE world.city
SET CountryCode = 'LX'
WHERE CountryCode = 'LUX';

Thread id sinin 111 olduğunu varsaydığımızda aşağıdaki satırları göreceğiz.

*************************** 1. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: NULL
 lock_type: TABLE
 lock_mode: IX
 lock_status: GRANTED
 lock_data: NULL

*************************** 2. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X
 lock_status: GRANTED
 lock_data: 'LUX', 2452

*************************** 3. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: PRIMARY
 lock_type: RECORD
 lock_mode: X,REC_NOT_GAP 
 lock_status: GRANTED
 lock_data: 2452

*************************** 4. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X,GAP
 lock_status: GRANTED
 lock_data: 'LVA', 2434

*************************** 1. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: NULL
 lock_type: TABLE
 lock_mode: IX
 lock_status: GRANTED
 lock_data: NULL

*************************** 2. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X
 lock_status: GRANTED
 lock_data: 'LUX', 2452

*************************** 3. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: PRIMARY
 lock_type: RECORD
 lock_mode: X,REC_NOT_GAP 
 lock_status: GRANTED
 lock_data: 2452

*************************** 4. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X,GAP
 lock_status: GRANTED
 lock_data: 'LVA', 2434

*************************** 1. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: NULL
 lock_type: TABLE
 lock_mode: IX
 lock_status: GRANTED
 lock_data: NULL

*************************** 2. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X
 lock_status: GRANTED
 lock_data: 'LUX', 2452

*************************** 3. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: PRIMARY
 lock_type: RECORD
 lock_mode: X,REC_NOT_GAP 
 lock_status: GRANTED
 lock_data: 2452

*************************** 4. row ***************************
 thread_id: 111
 event_id: 10
 object_schema: world
 object_name: city
 index_name: CountryCode
 lock_type: RECORD
 lock_mode: X,GAP
 lock_status: GRANTED
 lock_data: 'LVA', 2434

• lock_mode: IX → Tablo düzeyinde “bu tabloda satır kilitlendi” sinyali

• lock_mode: X,REC_NOT_GAP → Satır üzerinde doğrudan lock

• lock_mode: X,GAP → Satırlar arasındaki boşluğu (gap) kilitleme

• lock_mode: X,INSERT_INTENTION → Insert denemesi için bekleyen lock

2. Record Locks ve Next-Key Locks

• Record Lock: Belirli bir satırın kilitlenmesidir.

• Next-Key Lock: Record lock + gap lock kombinasyonudur.

Next-key lock sayesinde yalnızca seçilen satır değil, aynı zamanda onun etrafındaki boşluk da kilitlenir. Böylece phantom read (hayalet kayıt) problemleri engellenir.

3. Gap Locks

Gap lock, bir satırın kendisini değil, onun öncesindeki veya sonrasındaki boşluğu kilitler.

Örnek:

UPDATE table_xxx SET amount = 100 WHERE id BETWEEN 100 AND 200

UPDATE table_xxx SET amount = 100 WHERE id BETWEEN 100 AND 200

UPDATE table_xxx SET amount = 100 WHERE id BETWEEN 100 AND 200

Bu update table_xxx tablosundaki id si 100 ile 200 arası tüm kayıtlara update sırasında ya da transaction içerisinde lock koyar.

Burada tipik bir senaryo şu şekildedir:

1. id auto_increment bir alandır. 150 de bittiğini varsayalım.

2. yukarda verilen update bir transaction içerisinde çalıştırılır ama commitlenmez, ya da update uzun sürer.

3. başka bir transaction da aynı tabloya bir insert gelir. endirek olarak autoincrement ten dolayı id 151 i almaya çalışır ve lock ta kalır.

4. çalışan querylere bakınca bu insert i kilitleyecek hiç bir sorgu yokmuş gibidir ama gap lock oradadır ve sinsi sinsi kilidi vurmuştur :)

4. Insert Intention Locks

Bir transaction belirli bir aralığa yeni satır eklemek isterse, InnoDB insert intention lock oluşturur. Bu lock, gerçek bir engelleme değil, daha çok “bekleme sırası” bilgisidir. Özellikle auto_increment alma, semaforlar ya da index güncellemeler gibi işlemlerin oluşturduğu mini beklemeler gibi düşünülebilir.

Faydalı tarafı, birden fazla transaction’ın aynı aralığa insert denemesi yapabilmesini sağlar ve deadlock riskini azaltır.

5. Deadlock Senaryosu

Deadlock, iki transaction’ın karşılıklı olarak birbirini beklemesiyle oluşur.

Örnek:

Ardından taraflar birbirinin satırını güncellemeye çalışır:

Transaction 1:

BEGIN;
UPDATE city SET CountryCode = 'AAA' WHERE ID = 1001

BEGIN;
UPDATE city SET CountryCode = 'AAA' WHERE ID = 1001

BEGIN;
UPDATE city SET CountryCode = 'AAA' WHERE ID = 1001

Transaction 2:

BEGIN;
UPDATE city SET CountryCode = 'BBB' WHERE ID = 2002

BEGIN;
UPDATE city SET CountryCode = 'BBB' WHERE ID = 2002

BEGIN;
UPDATE city SET CountryCode = 'BBB' WHERE ID = 2002

Daha sonra her iki işlem de birbirinin satırını güncellemeye çalışır:

• T1 → UPDATE city SET CountryCode = 'CCC' WHERE ID = 2002;

• T2 → UPDATE city SET CountryCode = 'DDD' WHERE ID = 1001;

Ardından taraflar birbirinin satırını güncellemeye çalışır:

• T1 → UPDATE city SET CountryCode = 'CCC' WHERE ID = 2002;

• T2 → UPDATE city SET CountryCode = 'DDD' WHERE ID = 1001;

Sonuç: Deadlock ❌

InnoDB durumu algılar ve transactionlardan birini geri alır.

6. Deadlock Önleme İpuçları

• Erişim sırasını sabitleyin (tüm transaction’lar tabloları aynı sırada güncellesin).

• Kısa transaction’lar kullanın (lock süresini azaltır).

• Okuma ve yazmayı ayırın.

• İzolasyon seviyesini dikkatli seçin (READ COMMITTED bazı durumlarda daha güvenli olabilir)

Sonuç

InnoDB, satır bazlı lock mekanizmasını çok esnek kullanarak:

• Record Locks ile satırları,

• Gap Locks ile satırlar arasındaki boşlukları,

• Next-Key Locks ile ikisini birden,

• Insert Intention Locks ile ekleme denemelerini

kontrol altına alır.

Bu güçlü yapı sayesinde veri tutarlılığı korunur, ancak aynı zamanda deadlock riski de beraberinde gelir. Dolayısıyla geliştiricilerin bu lock türlerini anlaması, performanslı ve güvenilir transaction tasarımı için kritik öneme sahiptir.