Table lock — butun database jadvali yoki uning mantiqiy darajasiga qo‘llanadigan lock. U ko‘p satrni bitta lock entry bilan boshqaradi, ammo row-level lockka qaraganda parallelizmni ko‘proq cheklaydi. Lock mode’ga qarab boshqa transaction o‘qishi, yozishi yoki schema o‘zgartirishi mumkin yoki kutishi kerak bo‘ladi.
Lock rejimlari
Table-level shared lock bir nechta o‘quvchiga ruxsat berib, yozuvchilarni cheklashi mumkin. Exclusive table lock odatda boshqa read va writelar bilan nomos. Intent Shared va Intent Exclusive locklar esa table ostidagi row yoki page locklar mavjudligini bildiradi; ular o‘zlari barcha satrni lock qilgan degani emas.
Schema stability va schema modification locklari query compile/execute bilan ALTER TABLE kabi DDL o‘rtasida koordinatsiya qiladi. Oddiy SELECT row versionini o‘qisa ham schema o‘zgarishi bilan to‘qnashishi mumkin.
Qachon olinadi
Full-table bulk load, index rebuild, TRUNCATE, ayrim DDL va explicit LOCK TABLE amali table lock talab qilishi mumkin. Storage engine kichik locklar soni juda ko‘payganda escalation orqali table lockka o‘tishi mumkin. Optimizer katta qism yangilanishini oldindan bilsa lock overheadni kamaytirish uchun keng lock tanlashi ehtimoli bor.
Aniq xatti-harakat DBMS, engine, isolation va operation optioniga bog‘liq. “Online index build” ham qisqa metadata lock bosqichlariga ega bo‘lishi mumkin.
Afzallik va cheklov
Bitta table lock million row lockdan kam memory va management xarajati talab qiladi. Bitta writer butun jadvalni ketma-ket qayta ishlaganda bu samarali bo‘lishi mumkin. Ammo boshqa transaction aloqasiz satrni yangilasa ham kutadi. Issiq OLTP jadvalida qisqa table lock ham katta request navbatini hosil qiladi.
Reader-writer blocking MVCC bilan kamayishi mumkin, lekin schema va writer-writer conflict qoladi. Replica’da og‘ir report bajarish primary table lockini kamaytirishi mumkin, ammo replica lag va freshness hisobga olinadi.
Explicit lock
Application bir nechta querydan iborat hisobni barqaror jadval ustida bajarish uchun explicit table lock so‘rashi mumkin. Bu kuchli vosita bo‘lib, transaction imkon qadar qisqa saqlanadi:
BEGIN;
LOCK TABLE inventory IN EXCLUSIVE MODE;
-- muvofiqlashtirilgan o‘zgarishlar
COMMIT;
Sintaksis va lock mode nomlari vendor bo‘yicha farq qiladi. Lock olishdan oldin boshqa kerakli resurslar barqaror tartibda olinmasa deadlock xavfi oshadi.
Maintenance va deployment
Schema migration katta jadvalni rewrite qilsa uzoq exclusive lock olib xizmatni to‘xtatishi mumkin. Metadata-only o‘zgarish, online DDL, shadow table yoki bosqichli migration downtime’ni kamaytiradi. Migration avval productionga yaqin data hajmida sinovdan o‘tadi; kichik development jadvalidagi vaqt real holatni ifodalamaydi.
Lock timeout deploymentni cheksiz kutishdan saqlaydi. Ammo timeoutdan so‘ng DDL qisman bajarilganmi yoki to‘liq rollback bo‘lganmi tekshiriladi.
Kuzatuv
Wait graph table lockning blocker sessioni va mode’ini ko‘rsatadi. Lock egasining querysi tugagan, ammo transaction ochiq qolgan bo‘lishi mumkin. Connection pooldagi idle in transaction holati ayniqsa xavfli. Alert faqat uzoq lockni emas, kutayotgan session soni va biznes latency’sini ham o‘lchaydi.
Replica va read-only rejim
Read replica’da table lock local analytics querylarini o‘zaro muvofiqlashtirishi mumkin, ammo primarydagi writer lockini bevosita olmaydi. Shu bilan birga replication apply jarayoni schema yoki recovery conflict sabab queryni bekor qilishi mumkin. “Replica’da lock bo‘lmaydi” degan taxmin noto‘g‘ri; faqat conflict turi va data freshness boshqacha.
Bog‘liq tushunchalar
Row lock, Lock escalation, Intent lock, Schema lock, Exclusive lock, Online DDL, Transaction, Lock timeout