როგორ მუშაობს row lock-ები და MVCC InnoDB-ში და როგორ ავიცილებთ თავიდან deadlock-ებს?

Question

IT Interview Practice · Accepted Answer

InnoDB აერთიანებს ორ მექანიზმს. **MVCC** უბრალო `SELECT`-ებს საშუალებას აძლევს წაიკითხონ თანმიმდევრული snapshot ბლოკირების გარეშე, ამიტომ მკითხველები არასდროს ბლოკავენ ჩამწერებს. **Lock-ები** იცავენ ჩაწერას: `UPDATE`/`DELETE`/`SELECT ... FOR UPDATE` იღებენ row lock-ებს და InnoDB ასევე იყენებს **next-key lock**-ებს (სტრიქონი + მის წინ არსებული ხარვეზი) phantom-ების შესაჩერებლად REPEATABLE READ-ის ქვეშ.

## Deadlock-ები

Deadlock არის ციკლი: T1 იჭერს lock A-ს და უნდა B, ხოლო T2 იჭერს B-ს და უნდა A. ვერცერთი ვერ აგრძელებს. InnoDB **აღმოაჩენს ციკლს და უკან აბრუნებს ერთ ტრანზაქციას** (უფრო იაფ მსხვერპლს) 1213 შეცდომით, ამიტომ მეორე სრულდება.

```sql
-- T1                              -- T2
BEGIN;                             BEGIN;
UPDATE acct SET bal=bal-1          UPDATE acct SET bal=bal-1
  WHERE id=1;  -- ბლოკავს row 1       WHERE id=2;  -- ბლოკავს row 2
UPDATE acct SET bal=bal+1          UPDATE acct SET bal=bal+1
  WHERE id=2;  -- ელოდება T2-ს        WHERE id=1;  -- ელოდება T1-ს => DEADLOCK
-- ERROR 1213: Deadlock found; transaction rolled back
```

## მათი თავიდან აცილება

- **თანმიმდევრული lock რიგი** — ყოველთვის შეეხეთ სტრიქონებს ერთი და იმავე რიგით (მაგ. ზრდადი id). მაგალითი deadlock-ს იწვევს მხოლოდ იმიტომ, რომ ორი ტრანზაქცია ბლოკავს 1→2 და 2→1.
- **ტრანზაქციები მოკლედ შეინარჩუნეთ** — lock-ები აიღეთ გვიან, სწრაფად კომიტდით, ნუ იჭერთ lock-ებს ქსელის/მომხმარებლის ლოდინის განმავლობაში.
- **დაბლოკეთ მინიმუმი** — გააკეთეთ index თქვენს `WHERE`-ზე, რომ InnoDB ბლოკავდეს კონკრეტულ სტრიქონებს და არა დიაპაზონებს ან (index-ის გარეშე) ფაქტობრივად ყოველ სკანირებულ სტრიქონს.
- **ხელახლა სცადეთ 1213-ზე** — deadlock-ები ნორმალურია კონკურენციის ქვეშ; შეფუთეთ ტრანზაქცია აპლიკაციის დონის retry-ში.

```sql
SHOW ENGINE INNODB STATUS\G   -- LATEST DETECTED DEADLOCK ხსნის ვინ ვის ელოდა
```

## რატომ არის ეს მნიშვნელოვანი

რეალური თანადროულობის ქვეშ, lock კონკურენცია და deadlock-ები არის სხვაობა ბაზას შორის, რომელიც მასშტაბირდება და ისეთს შორის, რომელიც ჩერდება. იმის ცოდნა, რომ მკითხველები იყენებენ MVCC-ს (ამიტომ არ ბლოკავენ), რომ deadlock-ები მოსალოდნელი და retry-ებადია და რომ თანმიმდევრული lock რიგი აღკვეთს მათ უმეტესობას, არის ზუსტად ის, რასაც senior on-call სამუშაო მოითხოვს.

Deadlock-ები

მათი თავიდან აცილება

რატომ არის ეს მნიშვნელოვანი

დაკავშირებული კითხვები