Упростите запросы. Например, мне известны ситуации, в которых планы запросов сильно «плавали» при внешних соединениях (join) с представлениями (view), построенными на внешних соединениях.

И только если всё предыдущее не помогло, используйте подсказки MS SQL Server. Они порой дают великолепный непосредственный результат, но с ними необходимо проявлять осторожность – в другой ситуации, на других данных или с другой загрузкой вынужденный план запроса иногда сильно деградирует.

Немного сложнее приходится, в ситуации если вас устраивают выбранные индексы, но не устраивают методы и порядок слияния. MS SQL Server позволяет настраивать и эти моменты, но тут выбор возможностей очень ограничен. Вы можете сделать порядок соединений жёстко зависящим от порядка их упоминания в запросе (force order), выбрать метод соединения (loop|merge|hash join) или указать, что несколько строк в результирующем запросе вам нужны раньше других (FAST число строк). Будьте осторожны, выбирая соединение хэшированием (hash join). Оно даёт порой потрясающие результаты по производительности, но всегда требует очень много памяти. И когда вашему серверу перестанет ее хватать, такие запросы не только заметно деградируют по скорости, но сильно замедлят работу в целом. И наоборот, если сервер работает в состоянии нехватки оперативной памяти, изменение метода слияния с hash на loop может увеличить число логических чтений, но при этом волшебным образом уменьшить время выполнения запроса и облегчить работу серверу целиком.

Как лечить блокировки

Лечение блокировок очень часто делается командой kill. Что может быть проще: уничтожил головной процесс – и всё заработало! Но у этого подхода есть и отрицательные моменты. Первый – распределённые блокировки склонны повторяться. Так что не исключено, что через некоторое время вы будете дежурить в офисе весь день и всю ночь и держать палец над кнопкой kill. Второй – убивая головной процесс, мы теряем всю информацию о распределённой блокировке. Впоследствии мы можем так никогда и не узнать, что же на самом деле произошло, и не сможем принять меры к тому, чтобы ситуация больше не повторялась. Третья причина – далеко не всегда уничтожение головного процесса приведёт просто к перезапуску клиентского приложения. Иногда ценой вопроса является несколько дней работы целого подразделения.

Более правильным вариантом работы является продуманная стратегия блокировок. Но её нельзя делать без хорошего представления о конкретной системе и предметной области. Нужно знать, для каких запросов сгодятся «грязные данные» и какого рода неточности тут могут возникнуть. Некоторые проблемы можно лечить расстановкой подсказки nolock или переводом целых процессов на низший уровень изоляции транзакций. В других ситуациях может потребоваться исправление существенных ошибок проектирования. Например, представьте, что в одной таблице оказались данные справочного типа, запрашиваемые постоянно множеством процессов и активно изменяемые, и важные поля. Эта ситуация будет приводить к постоянным блокировкам – читающие процессы будут мешать изменяющим, и наоборот. Одно из решений – выполнять чтение справочных данных с флагом nolock. Но если это почему-то неприемлемо, то можно воспользоваться другим способом. А именно: разделить эту таблицы на две, с созданием на месте старой таблицы представления (view) с «instead of» триггерами. При этом процессы, запрашивающие справочную информацию, будут блокировать одну таблицу, а изменения с помощью триггеров будут выполняться на другой.