مستويات العزلة

إلى جانب التحديث الصريح، تحتوي المعاملات أيضًا على قواعد رياضية فطرية مخبأة في أعماق المحرك والتي تحكم مقدار الطاقة التي يجب إنفاقها لعزل كل تفاعل فردي بشكل افتراضي. وهذا ما يسمى مستوى العزل. في عالم SQL، نعرف أربعة معايير قياسية، من حيث القوة والأمان ولكن من الواضح أن العكس من حيث الأداء.

• READ UNCOMMITTED: جنون فوضوي، ستشهد معاملتك كل تغيير يجريه الآخرون بما في ذلك البيانات المؤقتة من الأشخاص في منتصف الطريق خلال البرامج النصية الخاصة بهم. لا أحد يستخدمه على قواعد البيانات الكبيرة، بسبب أخطاء القراءة القذرة المستمرة.
• READ COMMITTED: (افتراضي لـ Postgres). ستشاهد على الفور بيانات جديدة بمجرد أن يصدر طرف ثالث التزامًا، ولكن يمكن أن تقع ضحية للقراءات الوهمية (رؤية سجلات جديدة في منتصف الطريق خلال سير العمل الطويل) أو عرض متسق غير خطي.
• REPEATABLE READ: أثقل. طوال مدة جلسة النافذة الزمنية الكبيرة الخاصة بك، "أرى" قاعدة البيانات مجمدة في اللحظة التي بدأ فيها استعلامي، متجاهلاً تمامًا ومتجاهلًا حتى الالتزامات الرسمية التي أكملها أشخاص آخرون! إنه يحمي من ظهور السجلات بطريقة سحرية، مما يضمن الاستقرار.
• SERIALIZABLE: المستوى الإلهي (بطيء جدًا). يتعامل مع كل المعاملات المتداخلة عن طريق حظرها وتنفيذها بشكل تسلسلي في خط واحد، وإجهاض المعاملات المتصادمة بلا رحمة، والقضاء حتى على الاحتمال العلمي لأدنى تصادم، والتضحية بنسبة 90% من الإنتاجية العالية.

كيف يمكنك ضبطه؟

بدلاً من BEGIN; العادي تكتب:

BEGIN ISOLATION LEVEL SERIALIZABLE;

-- and you proceed normally with your hermetically sealed isolation
UPDATE products SET stock = 10;
COMMIT;

أو في بعض المتغيرات والمحركات الأقدم تقوم بتعيينه بعد البدء:

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

جربه بنفسك