Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Правила хорошего плана  [new]
пролетевший
Member

Откуда: от Михал Иваныча
Сообщений: 1314
Обычно все косяки по производительности вылезают почему то в production :-)
Ручками запускать запросы в студии и высматривать проблемы мне лениво ( а запросов в приложении сотни, некоторые вообще генерятся всякими ORM, их еще и вытащить надо ).
Поскольку вся работа с базой покрывается unit-тестами, то возникла идея автоматизировать. Теперь тесты не только функционал проверяют, но и на каждый запрос вытаскивают execution plan и анализируют его.
Теперь задача написать правила которые будут выводить информацию в каких запросах есть проблемы. Пока правила записаны как xpath-выражения, если в xml находится соответствующие структуры то генерится ошибка
Для начала анализирую:
- Table Scan
- Index Scan
- Sort
- Filter
- Bookmark Lookup
- Implicit Conversion
- Missed Index
Кто подскажет свои признаки, что запрос требует оптимизации ? правила могут быть сложными, тесты пишуться на Scala, можно и специальный язык описания сделать.
10 авг 12, 08:03    [12991325]     Ответить | Цитировать Сообщить модератору
 Re: Правила хорошего плана  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
пролетевший
- Table Scan
- Index Scan
- Sort
- Filter
- Bookmark Lookup
- Implicit Conversion
- Missed Index
Все эти псевдо-признаки плохих запросов будет встречаться в каждом третьем запросе. Кто будет разбирать эти сотни false-positives?

Из всех признаков в чистом виде я бы оставил только Missed Index. И то не всегда те индексы которые советует оптимизатор прям таки нужно создавать, в итоге все эти запросы будут помечены как "плохие".
С Implicit Conversion надо обязательно проверять что там конвертируется, потому что к константам оптимизатор тоже приписывает Implicit Conversion, что на самом деле не приводит к проблемам с производительностью. В 2012 кстати добавили Implicit Conversion warning в план выполнения.

И еще, запросы на тестовой и на продакшн базе могут генерить совершенно разные планы в зависимости от распределения данных и актуальности статистик.

пролетевший
Кто подскажет свои признаки, что запрос требует оптимизации ?
Запрос выполняется медленне чем того хотят пользователи.
10 авг 12, 08:36    [12991388]     Ответить | Цитировать Сообщить модератору
 Re: Правила хорошего плана  [new]
Сон Веры Павловны
Member

Откуда:
Сообщений: 6201
пролетевший,

сами по себе операторы плана мало что говорят именно о производительности/ресурсоемкости запроса, здесь нужны количественные показатели, и их анализ. Для одиночных запросов здесь можно использовать профайлер, для анализа же всего скопом готового решения (типа того, что делает в оракле связка SET SQL_TRACE ON и tkprof), насколько я знаю, нет. Но можно сделать что-то вроде этого.
10 авг 12, 09:57    [12991701]     Ответить | Цитировать Сообщить модератору
 Re: Правила хорошего плана  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
пролетевший,

Ищите ошибки расхождения оценочного числа строк с реальным. Сами по себе операторы ничего вам не дадут.
10 авг 12, 10:22    [12991894]     Ответить | Цитировать Сообщить модератору
 Re: Правила хорошего плана  [new]
Glory
Member

Откуда:
Сообщений: 104751
пролетевший
Для начала анализирую:
- Table Scan
- Index Scan
- Sort
- Filter
- Bookmark Lookup
- Implicit Conversion
- Missed Index

Для начала надо анализивать
table spool
index spool
10 авг 12, 10:47    [12992104]     Ответить | Цитировать Сообщить модератору
 Re: Правила хорошего плана  [new]
Mnior
Member

Откуда: Кишинёв
Сообщений: 6724
Sort - может быть задан явно - ORDER BY. Не знаю как это рассматривать - как ошибку ORM?
Bookmark Lookup, Implicit Conversion - а чё тут такого?
Missed Index - ну сервер тоже ошибается. :) Но лучше это анализить.

А чё hash join-ы это нормально в большинстве случаев?

Согласен с SomewhereSomehow, надо количества строк анализить - самый важный признак.
Запросы должны быть разделены по категориям. Где одна строка где несколько, а где отчёты. Рутина.

--
Белая зависть.
10 авг 12, 15:34    [12994549]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить