في LINQ-To-SQL، هل يجب علي استخدام NOLOCK لتحسين الأداء؟

Question

لقد جاء إلينا DBA بمعلومات تفيد بأن استعلامات LINQ الخاصة بنا تقوم بإنشاء عدة آلاف من الأقفال في قاعدة البيانات.قام أحد المطورين في فريقنا بالتنقيب في منشور Hanselman هذا كحل محتمل لمشكلتنا:

http://www.hanselman.com/blog/GettingLINQToSQLAndLINQToEntitiesToUseNOLOCK.aspx

يوفر سكوت 3 طرق في LINQ لإعداد NOLOCK.1) نطاق المعاملات (المفضل)، 2) SPROCS، 3) context.ExecuteCommand

نحن موقع إخباري بنسبة 99% من القراء، و1% من يكتبون، لذا فإن تركيزنا الرئيسي ينصب على سرعة الاسترجاع.يكون بدون قفل استراتيجية جيدة لجميع استعلامات LINQ-TO-SQL لدينا؟

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

هل NOLOCK هو حقًا الخيار الأفضل لموقع القراءات السريعة العديدة والقليل من التحديثات؟

تحديث:في SQL Server 2005 والإصدارات الأحدث، هل عزل اللقطة أفضل من NOLOCK؟لقد وجدت هذا للتوhttp://msdn.microsoft.com/en-us/library/ms179599.aspx

الذي يغطي قراءة اللقطة الملتزم بها.هذا يمنع حظر الكتابة، لكنه لا يعيد البيانات القذرة؟هل يجب استخدام هذا 90% من الوقت عبر NOLOCK؟

التحديث 2:ما يزعجني هو الجفاف

الجزء الذي يزعجني أكثر هو أنه من أجل تنفيذ نمط عدم القفل أو نمط اللقطة، لا بد لي من تغييره في كل طريقة استعلام LINQ-to-SQL (باستثناء تلك المستخدمة في التحديثات).هذه تنبعث منه رائحة انتهاك كبير لـ DRY.

Answer 1

لا يستحق شيئا: READ COMMITTED SNAPSHOT (أو على الأقل كان منذ أكثر من عامين) جيدًا بما يكفي لـ الموقع الذي تستخدمه.