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

Откуда: Нижний Новгород
Сообщений: 2380
 		(sql2017, sql2019)
столкнулся с такой проблемой (смотрим на картинке)
это отправная точка более навороченного запроса, и приводит оно к тому, что навороченный запрос в первом случае работает 20s, во втором 200ms
с хинтом option(use hint('FORCE_LEGACY_CARDINALITY_ESTIMATION')) или option(recompile) ((что вообще странно)) первый запрос работает так же как и второй.
с parameter sniffing = OFF, наоборот, второй работает как первый.

может кто объяснить поведение и для чего это сделано?

К сообщению приложен файл. Размер - 58Kb
15 янв 21, 16:03    [22263981]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
msLex
Member

Откуда:
Сообщений: 8730
 		Какой тип у t._Date_Time?
Что будет, если getdate()-10 заменить на dateadd(...) ?
15 янв 21, 16:08    [22263987]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		msLex,
ничего не изменилось.
да хоть так
declare @fromdate datetime = '20210105'
 select * from _Document151 t where t._Date_Time >= @fromdate;
 select * from _Document151 t where t._Date_Time >= '20210105';
15 янв 21, 16:23    [22263999]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8346
 		ShIgor,

надо бы статистики пересчитать в таком случае.
15 янв 21, 16:34    [22264010]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		Владислав Колосов,

первым делом.
15 янв 21, 16:35    [22264012]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8346
 		ShIgor,

вообще интересно, 10% времени занимает скан, а 90% на что уходит?
PS понял, это объёмы.

Сообщение было отредактировано: 15 янв 21, 16:34
15 янв 21, 16:38    [22264018]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
msLex
Member

Откуда:
Сообщений: 8730
msLex↑
Какой тип у t._Date_Time?
15 янв 21, 16:41    [22264023]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		Владислав Колосов,

не, % это Actual/Estimated
15 янв 21, 16:41    [22264025]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 8346
 		ShIgor,

засекретили секционирование? Почему просмотренные объемы разные?
15 янв 21, 16:41    [22264026]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		Владислав Колосов,

нет секционирования никакого
просмотренные объемы одинаковые (синим)
разница только в оценке (красным)

тип поля datetime2, но и declare @fromdate datetime2 - никакого влияния не оказывает, проверял

Сообщение было отредактировано: 15 янв 21, 16:41
15 янв 21, 16:43    [22264030]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		(не прицепилось чего-то)

К сообщению приложен файл. Размер - 74Kb
15 янв 21, 16:48    [22264040]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
invm
Member

Откуда: Москва
Сообщений: 9646
 		ShIgor,

Что-то вы не договаривете или не показываете....
В обоих показанных запросах - скан кластерного. Поэтому можно обоцениваться, но время работы должно быть примерно одинаковое.
А настолько разное оно будет, только если один из планов параллельный.
15 янв 21, 17:34    [22264087]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
ShIgor
Member

Откуда: Нижний Новгород
Сообщений: 2380
 		invm,

в приведенном примере вытащил все что мог..
никаких недоговорок.
и по времени/скорости/io статистике запросы практически не отличаются.
разница только в оценке

другое дело навороченный запрос, там 6 сущностей (на _Document151 change tracking), выборка по изменениям с последней запрошенной версии (немного, 1-3 записей в документе + 5-10 из табличных частей) и все это оборачивается в xml.
результирующий XML не больше 20Кб
однако поведение абсолютно такое-же, с параметром - 20!!! секунд, с вычислением или в LEGACY_CARDINALITY_ESTIMATION 0,2сек.
и источник проблемы именно в том, что неверная оценка практически на каждом этапе в плане, начиная вот с этого 151 документа.

грешил на СТ. отключал - не помогло
уровень совместимости на базах (от 110 (тоже не понял, вроде это legacy) до - 150) - не помогло
делал копии таблиц в другую базу - не помогло
на другой сервер (2016) - не помогло

осталось MAX_DOP на базе в 0 поставить, стоит 1, поэтому никаких параллельных планов пока.
15 янв 21, 19:05    [22264122]     Ответить | Цитировать Сообщить модератору
 Re: estimator 2014 и выше  [new]
invm
Member

Откуда: Москва
Сообщений: 9646
 		ShIgor,

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

Лучше давайте актуальные планы быстрого и медленного запроса.
15 янв 21, 19:39    [22264147]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить