Sql Query Optimization

Question

Я не настолько хорошо владею TSql (пишу с последних 4/5 месяцев), но я написал много запросов. Хотя я дал результаты, иногда я чувствую, что запросы не так оптимизированы. Я искал в Google и нашел много материалов об оптимизации запросов, и они просят изучить план запросов (фактический и предполагаемый) для повышения эффективности.

Как я уже говорил, я новичок в написании запросов, поэтому мне становится трудно понять эти решения. Но мне нужно научиться оптимизации запросов.

Может ли какое-нибудь тело помочь мне изначально, как и с чего мне начать?

Поиск в Интернете показывает, что SEEK лучше, чем SCAN (может быть это индекс или таблица). Как я могу добиться поиска по сканированию?

Затем они говорят, что предложение ORDER BY, т. Е. Сортировка обходится дороже. Тогда что обходится? Как я могу написать эффективный запрос?

Кто-нибудь может мне объяснить, с некоторыми примерами, какой тип запроса лучше, чем и в какой ситуации?

Отредактировано

Дорогие все,

Вы все ответили, и это мне очень поможет. Но я хочу сказать, что вы все много тренировались, чтобы стать экспертом. Когда-то, я думаю, вы все были такими же, как я. Итак, мой скромный запрос заключается в том, как вы все начали писать оптимизированный запрос. Я знаю, что нужно терпение, и я посвятим это. Я прошу прощения за мое неправильное утверждение.

Заранее спасибо

Answer 1

ORDER BY - неизбежное зло - нет пути против него.

См. Этот вопрос для решения поиска по индексу, сканирования и поиска закладок / ключей . И этот сайт очень хорош для методов оптимизации ...

Answer 2

Статьи, обсуждающие вопросы оптимизации запросов, часто бывают очень фактическими и полезными, но, как вы узнали, за ними может быть трудно следить. Это немного похоже на то, когда кто-то пытается изучить основные правила бейсбола, и все спортивные комментарии, которые он / она находит по этому вопросу, изобилуют аббревиатурами и стратегическими подробностями о пользе жертвоприношения кого-то в бите и других «внутри бейсбола» "мелочи ...

Так что вам нужно сначала изучить основы :

• структура (ы) хранилища базы данных
• структура индексов, кластеризованный и некластеризованный вид, многостолбцовые индексы
• концепция покрытия запроса
• селективность конкретного столбца
• недостаток индексов при работе с CRUD
• основные подзадачи / стратегии запроса: сканирование таблицы или индекса, поиск по индексу, сортировка, внутреннее-внешнее объединение и т. Д.
• файл журнала, модель восстановления данных.

Следующие ссылки относятся к MS SQL Server. Если это не та СУБД, которую вы используете, вы можете попробовать найти подобный материал для выбранной вами системы. На самом деле, до тех пор, пока вы понимаете, что реализация может отличаться, может быть полезно просмотреть документацию MS.
структуры хранения MS SQL
Страницы MS SQL и экстенты

Затем, когда вы начали это делать, изучите способ чтения планов запросов (даже если сначала не совсем понимаете), и все это должно привести вас к уровню, на котором вы начнете понимать смысл более продвинутые книги или статьи по теме. Я не знаю учебных пособий для планов запросов в Интернете (хотя я вполне уверен, что они существуют ...), но может пригодиться следующая методология: начните с простых запросов, просмотрите план запросов (если это возможно в графическом виде) мода), начните распознавать наиболее распространенные элементы: сканирование таблицы, поиск по индексу, сортировка, вложенные циклы ... Прочитайте подробные свойства этих экземпляров: примерный nb строк, процент стоимости и т. д. Когда вы найдете новый элемент, который вы не знать / понимать, используйте это ключевое слово, чтобы найти подробности в Интернете. Также: много экспериментирую.

Наконец, вы должны помнить, что хотя способ написания запроса и предоставляемый набор индексов и т. Д. Покрывают большую часть потребностей в оптимизации, существуют и другие источники оптимизации, например способ использования оборудования (основной Например, если файл данных и файл журнала находятся на разных физических дисках, мы можем значительно повысить производительность CRUD.

Answer 3

Поиск в интернете показывает, что SEEK лучше, чем SCAN (может быть индекс или таблица). Как я могу достичь искать по сканированию?

Добавьте необходимый индекс - если дополнительные затраты на INSERT и UPDATE (и дополнительное хранилище) являются общим выигрышем для ускорения поиска в ваших запросах.

Тогда они говорят, что предложение ORDER BY то есть сортировка обходится дороже. Тогда что работа вокруг? Как я могу написать эффективный запрос?

Добавьте необходимый индекс - если дополнительные затраты на INSERT и UPDATE (и дополнительное хранилище) являются общим выигрышем для ускорения упорядочения в ваших запросах.

Может кто-нибудь объяснить мне, с некоторыми примеры, какой тип запроса лучше чем и в чем ситуация?

Вы уже указали пару конкретных вопросов - и ответы были почти идентичны. Что хорошего было бы добавить еще шесть?

Выполнять запросы тестов над репрезентативными искусственными наборами данных (они должны напоминать то, что вы планируете иметь в производстве - если у вас маленькие таблицы размером с игрушку, планы запросов не будут репрезентативными или значимыми) попробуйте с и без индекса, который, как представляется, предлагается различными планами запросов, измерить производительность; промыть, повторить.

Требуется 10000 часов практики, чтобы быть хорошим во всем. Оптимизация схем БД, индексов, запросов и т. Д. Не является исключением; -).

Answer 4

Всегда убедитесь, что у вас есть индексы в ваших таблицах. Не слишком много и не слишком мало.

Используя sql server 2005, примените включенные столбцы в этих индексах, они помогают при поиске.

Порядок сортировки является дорогостоящим, если не требуется, зачем сортировать таблицу данных, если она не требуется.

Всегда фильтруйте как можно раньше, если вы уменьшите количество объединений, вызовов функций и т. Д., Как можно раньше, вы сократите время, затрачиваемое на все

• избегайте курсоров, если можете
• использовать временные таблицы / таблицы переменных для фильтрация, где это возможно
• удаленные запросы обойдутся вам
• запросов с суб выбирает в предложении, где может быть hurtfull
• Табличные функции могут быть дорогостоящими, если нет фильтруется

как всегда, нет строгого правила, и все должно приниматься на основе запроса.

Всегда создавайте запрос как можно более понятным / читабельным и оптимизируйте его при необходимости.

РЕДАКТИРОВАТЬ, чтобы прокомментировать вопрос:

Временные таблицы могут использоваться, когда вам требуется добавить индексы для временной таблицы (вы не можете добавлять индексы для таблиц var, кроме pk). В основном я использую таблицы переменных, когда могу, и в них есть только обязательные поля

DECLARE @Table TABLE( FundID PRIMARY KEY )

Я бы использовал это, чтобы заполнить свои идентификаторы группы фондов вместо того, чтобы объединять таблицы, которые менее оптимизированы.

Я прочитал пару статей на днях и, к своему удивлению, обнаружил, что таблицы var фактически создаются в базе данных tempdb

текст ссылки

Кроме того, я слышал и обнаружил, что таблицы UDF могут показаться «черным ящиком» планировщику запросов. Еще раз, мы склонны перемещать селекторы из табличных функций в табличные переменные, а затем объединять их в этих таблицах переменных. Но, как упоминалось ранее, сначала напишите код, а затем оптимизируйте, когда найдете узкие места.

Я обнаружил, что CTE могут быть полезны, но также и то, что когда уровень рекурсии растет, он может быть очень медленным ...