DATABASE · LOCKS · 2026
أنواع الـ Locks في قواعد البيانات
إزاي قاعدة البيانات بتدير آلاف الـ transactions في نفس الوقت من غير ما البيانات تتلخبط؟
0%
Section 00
يعني إيه Lock أصلاً؟
المشكلة اللي بيحلها
السيناريو الكلاسيكي
اتنين users بيحاولوا يعدلوا نفس الـ row في نفس الوقت
USER A · t=0
يقرا الرصيد
balance = 1000
SELECT balance FROM accounts WHERE id=1
USER B · t=0.001
يقرا الرصيد
balance = 1000
SELECT balance FROM accounts WHERE id=1
PROBLEM · t=0.5
الاتنين يخصموا 600
UPDATE: 1000-600 = 400
الفعلي: 1000-600-600 = -200 ⚠️
١. Lost Update
User A عدّل لـ 400، بعدها User B عدّل لـ 400 برضه. التحويل بتاع A اتفقد.
٢. الحل: Lock
User A بياخد lock على الـ row، User B بيستنى. بعد A ما يخلص، B يقرا القيمة الجديدة.
٣. النتيجة
A: 1000-600=400، بعدها B: 400-600=رفض (insufficient funds). صح.
تخيل إنك في مكتبة. عاوز تكتب في كتاب معين تعديل. لو ٥ ناس بيكتبوا في نفس الصفحة في نفس الوقت، النتيجة هتبقى كارثة. الـ Lock هو زي إنك تقفل الصفحة لما تيجي تعدلها، والباقي يستنوا.
في قواعد البيانات، الـ lock هو آلية بتمنع عمليتين أو أكتر من إنهم يعدلوا نفس البيانات في نفس الوقت بشكل بيخرّب النتيجة.
📖 مصطلحات أساسية:
- transaction: مجموعة عمليات DB بتتنفذ كوحدة واحدة (يا كلها تنجح يا كلها تفشل)
- concurrency: تزامن، يعني أكتر من عملية شغالين في نفس الوقت
- contention: تنازع، لما transactions كتير عاوزين نفس الـ resource
- blocking: transaction مستنية lock من transaction تانية تخلص
- granularity: مستوى تفصيل الـ lock (row, page, table)
ليه محتاجين locks أصلاً؟
✓ مع locks
- ← البيانات بتفضل consistent
- ← مفيش lost updates
- ← العمليات الحساسة (فلوس) آمنة
- ← الـ ACID guarantees بتشتغل
✗ من غير locks
- ← race conditions في كل حتة
- ← بيانات بتتفقد أو بتتكرر
- ← لو حسابات مالية: كارثة قانونية
- ← bugs مستحيل تكتشفها في dev
⚡ الفكرة الجوهرية
الـ locks هي trade-off: أمان البيانات مقابل الأداء. كل ما زادت الـ locks، الأمان بيزيد بس الـ concurrency بيقل. الفن إنك تحقق الأمان اللي محتاجه بأقل locks ممكنة.
أسئلة انترفيو على القسم ده
3القسم 1 / 13