В LinQ-To-SQL следует использовать Nolock для повышения производительности?

Question

Наша DBA пришла к нам с информацией о том, что наши запросы LINQ создают много тысяч замков в базе данных. Разработчик в нашей команде выкопал этот пост Hanselman в качестве возможного решения нашей проблемы:

http://www.hanselman.com/blog/gettinglinqtoSqlandlinqtoEntitiTityseNolock.aspx < / P >.

scott предоставляет 3 способа в Linq для настройки nolock. 1) DescractsCope (предпочтительно), 2) SPROCS, 3) CONTEXT.EXECUTECOMMAND

Мы являемся новостным сайтом, который составляет 99% чтения, 1% пишет, поэтому наше основное внимание уделяется скорости поиска. nolock хорошая стратегия для всех наших запросов linq-to-sql?

То, что я пытаюсь понять, это Почему использует nolock - это или не хорошая идея. Должно быть много людей с нашими же целями: многие быстро читают, мало не обновляются. Если Nolock является очевидным ответом, то почему не так уныло по умолчанию? Почему я не могу сделать это по умолчанию в контексте, вместо того, чтобы установить его в каждом вызове данных?

Nolock действительно лучший вариант для многих быстрого читания, мало обновлений?

Обновление: в SQL Server 2005 и выше, является изоляция снимка лучше, чем nolock? Я только что нашел это http://msdn.microsoft.com/en-us/library/ms179599.aspx

, в котором охватывает прочитанный моментальный снимок . Это предотвращает запись-блок, но не возвращает грязные данные? Должно ли это использовать 90% времени над нолоцкой?

<Сильное> Обновление 2: Что беспокоит меня, это сухой

Часть, которая беспокоит меня, в том, что для реализации либо шаблона без блокировки, либо моментального момента, я должен изменить его на каждом методе запроса Linq-to-SQL (кроме тех, которые используются в обновлениях). Это пахнет значительным нарушением сухого.

Answer 1

Worth noting: READ COMMITTED SNAPSHOT is (or at least was 2+ years ago) good enough for the site you're using.