У вас есть правильная стратегия и операторы с TransactionOptions
и IsolationLevel.ReadUncommitted
, чтобы помочь использовать NOLOCK
в ваших операторах SQL. Гансельман предлагает это !
Возникает вопрос, являются ли операторы SQL, сгенерированные LINQ To SQL, производительными для базы данных.Помните, что Dev против Test и Prod будут работать по-разному, в зависимости от количества строк в вашей таблице и типов данных в вашем запросе.
Некоторые вещи для проверки:
Что за оператор SQL отправляется на сервер?Проверьте с помощью SQL Profiler.Работает ли этот SQL своевременно в специальном запросе через SSMS?
Есть ли индекс для столбца msg_shortdesc
?Добавьте новый индекс, если он не существует, в эту таблицу для этого столбца.Повторите ваш запрос LINQ To SQL, чтобы проверить его производительность.
Похоже, у вас нет возможности изменить конфигурацию базы данных (индексы).Предположим, что без возможности вносить изменения в конфигурацию вы не сможете сделать «правильные» настройки для повышения производительности.К сожалению, вы будете постоянно зависеть от случайности нагрузки, создаваемой другими пользователями.
Если вы абсолютно не можете создать индекс, рассмотрите стратегию кэширования для этого набора данных.Возможно, загрузите эти данные в Session
и просрочите их каждые n минут.