Используете NOLOCK Hint в EF4?

NOLOCK = "READ UNCOMMITTED" = грязное чтение

Я предполагаю, что MS знает, почему они выбрали уровень изоляции по умолчанию как «READ COMMITTED»

NOLOCK, как и любую подсказку, следует использовать очень разумно: не по умолчанию.

Ваш администратор базы данных - кукла. См. Это (SO): Что может произойти в результате использования (nolock) для каждого оператора SELECT на сервере SQL?. Если вы работаете в банке или любом учреждении, где у меня может быть счет, сообщите мне, и я смогу его закрыть.

Я разработчик в группе инструментов в организации SQL в Microsoft. Я никоим образом не уполномочен делать какие-либо официальные заявления, и я уверен, что на SO есть люди, которые знают об этих вещах больше, чем я. Тем не менее, я предлагаю дружеское практическое правило по теме «Преждевременная оптимизация - корень всех зол»:

Не используйте NOLOCK (или любые другие подсказки в этом отношении), пока вам не понадобится. Если у вас есть оператор select, который имеет приличный план запроса, и он отлично работает, когда в системе очень мало другой нагрузки, но затем он замедляется, когда другие запросы обращаются к той же таблице, попробуйте добавить некоторые подсказки NOLOCK. Но всегда помните, что когда вы это сделаете, вы рискуете получить противоречивые данные. Если вы пишете какое-то критически важное приложение, которое выполняет онлайн-банкинг или управляет самолетом, это может быть неприемлемо. Однако для многих приложений ускорение производительности стоит риска. Однако оценивайте в индивидуальном порядке. Не используйте их волей-неволей повсюду.

Если вы решите использовать NOLOCK, у меня есть решение в блоге в C # с использованием методов расширения, чтобы можно было легко изменить запрос LINQ для использования подсказок NOLOCK. Если вы можете адаптировать это к EF4, опубликуйте свою адаптацию.

EF4 в настоящее время не имеет встроенного способа сделать это, ЕСЛИ ef4 генерирует все ваши запросы.

Есть способы обойти это, например использовать хранимые процедуры или более расширенную модель встроенных запросов, однако это может занять много времени, если не сказать больше.

Я считаю (и не говорю от лица Microsoft по этому поводу), что кеширование - это решение Microsoft, предназначенное для облегчения нагрузки на сервер на сайтах EF4. Чтение незафиксированных (или nolock), встроенных в фреймворк, может создать непредсказуемые проблемы для ожидаемого поведения EF4 при одновременном запуске двух контекстов. Это не означает, что в вашей ситуации требуется такой уровень параллелизма.

Похоже, вас попросили заблокировать ВСЕ варианты выбора. Хотя я согласен с предыдущим постером, что это может быть опасно, если у вас есть ЛЮБЫЕ транзакции, которые должны быть транзакциями, я не согласен, что администратор баз данных автоматически превращается в маппет. Возможно, вы просто используете CMS, которая отлично подходит для грязного чтения. Вы можете изменить УРОВЕНЬ ИЗОЛЯЦИИ для всей базы данных, что может иметь тот же эффект.

Администратор базы данных, возможно, рекомендовал nolock для операций, которые были ТОЛЬКО выбранными (что нормально, особенно если есть ORM, который неправильно загружается и делает некоторые хитрые дампы данных). Самым забавным в этом комментарии маппета является то, что сам Stack Overflow запускает SQL-сервер в режиме READ UNCOMMITTED. Думаете, вам нужно найти другое место, чтобы получить ответы на свои проблемы?

Поговорите со своим администратором баз данных о возможности настройки этого параметра на уровне базы данных или рассмотрите стратегию кэширования, если она вам нужна только в нескольких местах. В конце концов, Интернет не имеет состояния, поэтому параллелизм часто может быть иллюзией, если вы не решите его напрямую.

Информация об уровнях изоляции

Проработав с EF4 более года, я предлагаю, чтобы использование хранимых процедур для конкретных задач было не взломом и абсолютно необходимо для обеспечения производительности в определенных ситуациях.

Наша платформа получает много трафика через наш веб-сайт, API и каналы данных ETL. Мы используем EF в основном на нашей веб-стороне, но также и для некоторых внутренних процессов. Иногда EF отлично справляется с генерацией запросов, иногда - ужасно. Вам нужно посмотреть на генерируемые запросы, загрузить их в анализатор запросов и решить, может ли вам лучше написать операцию другим способом (хранимая процедура и т. Д.).

Если вы обнаружите, что вам нужно сделать данные доступными через EF и вам нужно NOLOCKs, вы всегда можете создать представления с NOLOCK подсказками и предоставить представление в EF вместо базовой таблицы. То же самое можно сделать с хранимыми процедурами. Эти методы, вероятно, будут немного проще, если вы используете подход Code First.

Но я думаю, что одна ошибка, которую делают многие люди с EF, заключается в том, что они считают, что объектная модель EF должна напрямую отображаться на физическую (табличную) модель в базе данных. Это не так, и именно здесь ваш администратор баз данных вступает в игру. Позвольте ему спроектировать вашу физическую модель, и вы вместе работаете над абстрагированием своей логической модели данных, которая отображается на вашу объектную модель в EF.

Хотя это было бы основной задачей PITA, вы всегда можете отбросить свой SQL в хранимой процедуре и получить функциональность, которая вам нужна (или вынуждена). Хотя это определенно взлом!

Я знаю, что это не ответ на ваш вопрос, но я просто хотел добавить его.

Мне кажется, что это (по крайней мере частично) работа администратора базы данных. Можно сказать, что приложение должно вести себя определенным образом, и вы можете и обязательно должны пытаться запрограммировать его так, как ему хочется.

Однако единственный способ быть уверенным - это для администратора базы данных работать над приложением вместе с вами и построить поверхность БД, которую он хотел бы представить приложению. Если он хочет, чтобы критические таблицы запрашивались как READ UNCOMMITTED, он должен помочь предоставить набор хранимых процедур с правильным уровнем доступа и изоляции.

Использование кода приложения для правильного построения каждого специального запроса не является масштабируемым подходом.