SQL-Ex blog

1. Сразу проверьте свойства первого оператора (SELECT/DELETE/INSERT). Здесь тонны информации, но люди часто просто игнорируют её. Вы можете увидеть, основан ли план на полной оптимизации, или нет. Это сразу же подскажет мне, работаю ли я с лучшей оценкой оптимизатора в плане или наблюдаю тайм-аут. Если это тайм-аут, я знаю, что не могу рассчитывать на хороший план. Я также получаю значения параметров времени компиляции и времени выполнения, которые помогают обнаружить в свойствах проблемы прослушивания параметра.


2. Предупреждения. Если вы видите предупреждение no join predicate (нет предиката соединения), это сразу должно подсказать вам, куда смотреть. То же самое с отсутствующей статистикой. Также важно знать о новых предупреждениях в планах 2012. Эта лежащая на поверхности информация сразу указывает направление вопросов к плану.


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


4. Толстые линии. На самом деле, это обычно просто показатель объема данных, и знание того, что вы перемещаете много строк, помогает прочитать план (может возникнуть проблема с соединением многих миллионов строк в цикле). Но настоящий сигнал опасности звучит, когда вы видите толстые линии, входящие в тонкие, или тонкие, входящие в толстые, или даже тонкий-толстый-тонкий. Это серьезный сигнал.


5. Лишние операторы. Это напоминает старое соображение о порнографии: "Я не могу дать вам точного определения, но я знаю, когда её вижу." Поиск того, что не относится к делу. Например, у вас нет ни одного оператора ORDER BY, но в плане есть оператор Sort. Почему? Этот индикатор "лишнего оператора" подскажет мне копать глубже.


6. Сканирование. Сканирование - это не обязательно плохо, а поиск - это не обязательно хорошо (тут можно об этом почитать). В общих чертах, при небольших наборах данных вы, как правило, должны увидеть Seek, а не Scan. Сканирование может быть правильным и лучшим выбором, особенно для очень больших наборов данных и в других случаях, но они являются индикатором потенциальных проблем.

После этого у вас будет еще масса вещей для развлечения. Table Spool в операторах SELECT обычно не есть хорошо. Поищите индикаторы многооператорных UDF (сканирование с нулевой стоимостью). Соединения вложенными циклами, когда соединение слиянием имеет больше смысла. Слияние (merge join), когда вы должны бы увидеть хэш-соединение, информация об отсутствующих индексах, несоответствие между оценочными и фактическими значениями, и т.п. Вы получили стартовую точку. План выполнения содержит тонны и тонны информации. Но этот список из шести пунктов обычно то, на что следует обратить внимание в первую очередь.