Давненько я хотел написать что-нибудь на эту тему. Однако, пока я собирался с мыслями и силами, наткнулся на уже написанную статью Slow in the Application, Fast in SSMS? Understanding Performance Mysteries Erland-а Sommarskog, которая исчерпывающе отвечает на поставленный вопрос. Так что мне осталось только представить перевод этой статьи, который я для удобства разделил на три
Выбор полей для кластерного индекса
Существуют разные точки зрения на тему, какое поле лучше всего подходит в качестве кластерного индекса для таблицы. В частности такое «кластерный индекс должен удовлетворять запросам для выбора большого числа строк, желательно что бы это не было поле identity, т.к. при такой организации могут возникать hotspot при вставке, а выбор по диапазону identity явление очень редкое».
Некоторые случаи необрабатываемые блоком try/catch
Возможно, не все знают, что в t-sql конструкция try catch обрабатывает не все ошибки. Это поведение хорошо документировано, но может стать сюрпризом для людей привыкших работать с классическим try/catch в объектно-ориентированных языках. Подробно это описано в документации TRY…CATCH (Transact-SQL), Использование конструкции TRY…CATCH в языке Transact-SQL — я же просто приведу некоторые примеры, на которые наталкивался
Можно ли отсортировать результаты во вью?
Ответ: можно, но это не правильно, т.к. недокументировано. Согласно документации предложение order by запрещено во вью (если не указан оператор top, но и тогда порядок не гарантируется) и если вам нужно получить отсортированный результат из вью — то предложение order by необходимо указывать в запросе к этому вью. Тем не менее, отсортированные данные получить все-таки
Как отключение FK на момент загрузки, может повлиять на план запроса после загрузки
Если в таблице создано ограничение внешнего ключа (Foreign Key Constraint), то при добвлении данных в эту таблицу будет проверяться наличие/отсутствие соответствующих записей в «родительской» таблице. Иногда, если загрузка данных идет из, условно говоря, доверенного источника (имеется ввиду нам известно, что все данные из источника отвечают требованиям ссылочной целостности), для ускорения загрузки ограничения внешних ключей отключают,
Достаточно ли обновить статистику после загрузки данных, только по явно используемым индексам
Периодически возникает задача загрузить какую-то порцию данных в уже имеющуюся таблицу, чтобы потом, например, построить по ним отчет или выполнить еще какие-то действия. Иногда, после загрузки большой (относительно количества уже имеющихся данных в таблице) порции данных, запрос, который используется для построения отчета, может начать «тормозить» при первом выполнении. И хотя потом все начинает работать так
Вариант использования процедур sp_trace_XXX для долгосрочной трассировки
Необходимость трассировки возникла после жалоб пользователей одного из офисов нашей компании на «внезапно появляющиеся» и столь же «внезапно исчезающие тормоза». Были исследованы планы предположительно «тормозящих» запросов, блокировки, счетчики сервера, канал связи, но явных проблем нигде не обнаружилось. По этому возникла резонная мысль посмотреть, а что происходит на сервере в этот момент, и главное когда именно
Получить в триггере текст запроса
Несколько раз встречал подобные вопросы в форумах. Задача, формулируется примерно так. Получить в триггере текст команды, которая привела к тому, что этот триггер сработал. Это может быть полезно если мы, например, хотим увидеть/залогировать конкретный запрос, который привел к изменению данных. Сразу скажу, что штатный механизм для обеспечения этого на сегодняшний день, в версиях 2000, 2005,