Недавно на одном из форумов был задан вопрос о том, почему при добавлении в запрос условия isnumeric(column)=0, запрос начинает выполняться очень медленно. Изучение этой ситуации привело к интересным результатам.
RowGoal и неравномерное распределенных данных
На написание этой заметки меня подвиг доклад Алексея Эксаревского на 24 hours of PASS про наиболее часты причины ошибок в оценке кардинальности. Те, кто не видел этот доклад могут ознакомиться с ним на techdays. Алексей рассказывает о возможных причинах неправильных оценок кардинальности (или количества строк), из-за чего оптимизатор выбирает неудачный план запроса. Наиболее интересным и
Оптимизатор (недокументированное): Отключить правила преобразования в отдельном запросе
Многие, кто интересуется внутренним устройством оптимизатора, уже наверняка знают, что такое правила преобразования и то, что их можно отключить в сессии при помощи dbcc ruleoff/ruleon. В этой короткой заметке мы посмотрим на недокументированный хинт, который позволяет отключать правила преобразования в отдельно взятом запросе. Прим: Те, кто не знают про правила преобразования, но интересуются, могут обратиться
Оптимизатор (ч.4): Optimization: Full Optimization: Search 1
Optimization: Full Optimization: Search 1 В данном разделе: — update statistics with row_count, page_count; — преобразования memo; — параллельный план; Данная фаза, называется также Quick Plan. Как мы уже говорили, запросы могут миновать стадию Transaction Processing (search 0), и сразу перейти к этой фазе, если в запросе менее трех таблиц. Также эта фаза примечательна
Оптимизатор (ч.3): Optimization: Full Optimization: Search 0
Optimization: Full Optimization: Search 0 В этом разделе: — определение стадий оптимизации, которые проходит запрос; — структура для поиска альтенатив memo; — оператор Apply lookup в nested loops join; — оценки и вычисления селективности запроса с несколькими предикатами; — стоимость операторов; — Rebind, Rewind, RowGoal; — просмотр начального и конечного memo; — выходное дерево физических
Оптимизатор (ч.2): Optimization: Trivial Plan Optimization
Optimization: Trivial Plan Optimization В этом разделе: — применение правил преобразования; — особенности стадии trivial plan; — почему загружается статистика; — как пропустить фазу поиска тривиального плана (upd) Итак, мы получили наше упрощенное дерево. Но как оптимизатор догадался его упростить, что именно сделал. Разберемся. Для начала, немного теории.
Оптимизатор (ч.1): Введение, Optimization: Simplification
Введение В этом разделе: — обзор; — упрощение, исключение противоречий и лишних соединений; — просмотр дерева логических операций; В данной заметке рассматриваются некоторые механизмы работы оптимизатора. Она будет интересна тем, кто хочет больше узнать о процессе преобразования запроса в план запроса, который и будет передан серверу на выполнение. Многие средства, используемые в заметке — недокументированны,
Дополнительные чтения в nested loops
Недавно, просматривая статистику ввода вывода одного из запросов, я обнаружил дополнительные чтения там, где по-идее их быть не должно. Мне стало интересно, откуда они берутся и я попробовал разобраться.