Row lock — relational database jadvalidagi alohida satr yoki uning indeks kalitiga qo‘llanadigan lock. U bir transaction ma’lum satrni o‘zgartirayotgan paytda boshqa transactionlarning zid amallarini cheklab, jadvalning boshqa satrlarida parallel ishlashga imkon beradi.
Lock qilinadigan obyekt
“Row lock” nomiga qaramay, storage engine fizik row emas, primary key yoki indeks entry’sini lock qilishi mumkin. Update qaysi satrlarni topish uchun indeksdan foydalansa locklar shu access path bo‘ylab olinadi. Indeks bo‘lmasa katta scan ko‘p satrni tekshirishi va ko‘proq lock yoki table-level cheklov keltirishi mumkin.
Mavjud bo‘lmagan key uchun insert conflictini cheklashda gap, next-key yoki key-range lock ishlatiladi. Bu faqat row lockdan kengroq intervalni himoya qilib, phantom va duplicate insertni boshqaradi.
O‘qish va yozish
Row shared lock o‘quvchilar bilan mos bo‘lishi, row exclusive lock esa zid reader yoki writerni kutdirishi mumkin. MVCC tizimida oddiy o‘quvchi eski committed versionni ko‘rib writer’ni bloklamaydi. FOR UPDATE query topilgan rowlarni kelajak update uchun lock qiladi:
SELECT id, status
FROM jobs
WHERE id = 42
FOR UPDATE;
Transaction rowni tekshiradi, keyin uning holatini yangilaydi. Lock commit yoki rollbackgacha saqlanadi.
Parallel worker modeli
Queue jadvalidan ish oladigan workerlar SKIP LOCKED kabi imkoniyat bilan boshqa worker lock qilgan rowni tashlab, keyingi tayyor ishga o‘tishi mumkin. Bu throughputni oshiradi, ammo qat’iy FIFO tartibini buzishi va doim locklangan row starvationga uchrashi mumkin. Retry va stuck-job monitoring kerak.
Escalation va metadata
Millionlab row lock lock manager memory’sini sarflaydi. Ayrim DBMSlar threshold’dan oshganda page yoki table lockka escalation qiladi. Natijada boshqa satrlardagi transactionlar ham bloklanadi. Boshqa engine’lar escalation qilmay, lock metadata’sini boshqacha boshqarishi mumkin.
Batch update’ni kichik transactionlarga bo‘lish lock soni va log bosimini kamaytiradi, lekin butun batchning atomicity chegarasini o‘zgartiradi. Oraliq holat biznes uchun ruxsat etilishi kerak.
Deadlock
Transaction A avval row 1, keyin row 2ni; transaction B esa teskari tartibda olsa deadlock yuz beradi. Primary key bo‘yicha barqaror tartibda lock olish ehtimolni kamaytiradi. Query optimizer boshqa access plan tanlasa amaldagi lock tartibi o‘zgarishi mumkin, shuning uchun deadlock graph real resource va statementni ko‘rsatadi.
Foreign key tekshiruvi parent yoki child indekslarda qo‘shimcha lock olishi mumkin. Ko‘rinishidan bitta row yangilangan bo‘lsa ham constraint va triggerlar boshqa resursga tegadi.
Diagnostika
Blocking sessionni topishda transaction age, query plan, locked key va wait mode ko‘riladi. Row identifierni business keyga tarjima qilish indeks metadata’sini talab qilishi mumkin. Uzoq open transaction MVCC cleanupni ham ushlab qoladi. Lock hint bilan muammoni yashirishdan oldin sekin statement, yetishmagan indeks va noto‘g‘ri transaction chegarasi aniqlanadi.
Partitionlangan jadval
Table partitionlangan bo‘lsa row lock ma’lum partitiondagi indeks va satrlarga tegadi. Partition pruning ishlamasa query boshqa partitionlarni ham skanerlashi va keraksiz lock olishi mumkin. Partition almashtirish yoki detach qilish esa metadata/table lock bilan to‘qnashadi. Row granularligi maintenance amallarining kengroq lock ehtiyojini bekor qilmaydi.
Bog‘liq tushunchalar
Exclusive lock, Shared lock, Key-range lock, Lock escalation, SELECT FOR UPDATE, MVCC, Deadlock, Index