Несколько факторов влияют на стоимость запроса.
Во-первых, есть ли соответствующие индексы для использования. Поля, которые используются в объединении, почти всегда должны быть проиндексированы, а внешние ключи по умолчанию не индексируются, разработчик базы данных должен их создавать. Поля, используемые в классах where, часто также нуждаются в индексах.
Далее, можно ли использовать предложение where, другими словами, может ли оно использовать индексы, даже если у вас есть правильные индексы? Плохое предложение where может повредить запросу гораздо больше, чем объединение или дополнительные столбцы. Вы не можете получить ничего, кроме сканирования таблицы, если используете синтаксис, который запрещает использование индекса, такого как:
LIKE '%test'
Далее, вы возвращаете больше данных, чем вам нужно? Вы никогда не должны возвращать больше столбцов, чем вам нужно, и вы не должны использовать select * в производственном коде, так как он имеет дополнительную работу для поиска столбцов, а также очень хрупок и подвержен созданию плохих ошибок, поскольку структура меняется со временем.
Вы присоединяетесь к таблицам, к которым не нужно присоединяться? Если таблица не возвращает столбцы в select, не используется в where и не отфильтровывает записи, если объединение удалено, то у вас есть ненужное объединение, и оно может быть устранено. Ненужные объединения особенно преобладают, когда вы используете много представлений, особенно если вы допустили ошибку при вызове представлений из других представлений (что может привести к снижению производительности). Иногда, если вы проследите через эти представления, которые вызывают другие представления, вы будете увидеть одну и ту же таблицу, присоединенную несколько раз, когда это не было бы необходимо, если бы запрос был написан с нуля вместо использования представления.
Мало того, что возвращение большего количества данных, чем вам нужно, заставляет SQL Server работать больше, оно заставляет запрос использовать больше сетевых ресурсов и больше памяти веб-сервера, если вы храните результаты в памяти. Это плохой выбор.
Наконец, вы используете известные неэффективные методы, когда доступны лучшие. Это может включать использование курсоров, когда альтернатива на основе набора лучше, использование коррелированных подзапросов, когда объединение будет лучше, использование скалярных пользовательских функций, использование представлений, которые вызывают другие представления (особенно если вы вкладываете более одного уровня. Большинство из этих плохих методов включают обработку строки за агонизирующей строкой, которая обычно является худшим выбором в базе данных. Чтобы правильно запрашивать базы данных, вам нужно думать с точки зрения наборов данных, а не обрабатывать одну строку за раз .
Есть еще много вещей, которые влияют на производительность запросов и базу данных, чтобы действительно овладеть этим предметом, вам нужно прочитать несколько книг по этому предмету. Это слишком сложная тема, чтобы обсуждать ее на доске объявлений.