Я новичок в sql server,
мой менеджер дал мне работу, где я должен узнать производительность запроса в sql server 2008.
Этот запрос очень сложен, поскольку он имеет соединения между представлениями и таблицей. Я читал в Интернете, что объединение представлений и таблиц приводит к снижению производительности?
Может ли мне в этом помочь специалист? Любая хорошая ссылка, по которой я нашел информацию об этом? Как рассчитать производительность запроса на сервере sql?
Посмотрите на план запроса - он может быть чем угодно. Отсутствуют индексы в одной из базовых таблиц представления, отсутствуют индексы в объединенной таблице или что-то еще.
Взгляните на эту статью Гейл Шоу о поиске проблем с производительностью в SQL Server - часть 1, часть 2.
Представление (которое не проиндексировано / материализовано) - это просто макрос: ни больше, ни меньше
То есть он расширяется во внешний запрос. Таким образом, соединение с 3 представлениями (с 4, 5 и 6 соединениями соответственно) становится одним запросом с 15 JOIN.
Это распространенная ошибка «Я могу использовать это повторно»: DRY обычно не применяется к коду SQL.
В противном случае см. Ответ Одеда.
Одед прав, вам обязательно стоит начать с плана запроса. Тем не менее, есть несколько вещей, которые вы уже можете увидеть на высоком уровне, например:
ПРЕОБРАЗОВАТЬ (VARCHAR (8000), CN.Note) КАК '% T B9997%'
LIKE поисковые запросы с подстановочным знаком впереди - плохие новости с точки зрения производительности из-за того, как работают индексы. Если задуматься, в телефонной книге легко найти всех людей, чьи имена начинаются с «Smi». Если вы попытаетесь найти всех людей, у которых есть «mit» в любом месте своего имени, вы обнаружите, что вам нужно прочитать всю телефонную книгу. SQL Server делает то же самое - это называется полным сканированием таблицы и обычно выполняется довольно медленно. Другая проблема заключается в том, что левая часть условия использует функцию для изменения столбца (в частности, преобразования его в varchar). По сути, это снова означает, что SQL Server не может использовать индекс, даже если он был для столбца CN.Note.
Я предполагаю, что столбец - это text столбец, и вам не будет разрешено изменять логику фильтра, чтобы удалить подстановочный знак в начале поиска. В этом случае я бы порекомендовал изучить полнотекстовый поиск / индексирование функциональность. Включив полнотекстовое индексирование и используя определенные ключевые слова, такие как CONTAINS, вы должны повысить производительность.
Опять же (как и во всех сценариях оптимизации производительности) вам все равно следует начать с плана запроса, чтобы увидеть, действительно ли это самая большая проблема с запросом.
