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

Откуда: Msk ->NL
Сообщений: 308
Не то чтобы вопрос жизни и смерти, но концепция что SARGable, а что нет прям у меня на глазах рушится. Наверно давно планы не отлаживал или какой твиттер упустил.

Предикаты распарились в DATEPART и индекс был успешно заюзан.
Для доп. анализа вот еще

(54429 rows affected)
Table 'RETURNED_ITEM_2'. Scan count 5, logical reads 169985, physical reads 1514, read-ahead reads 6626, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 1140 ms, elapsed time = 1231 ms.
CPU time = 0 ms, elapsed time = 0 ms.

(54429 rows affected)
Table 'RETURNED_ITEM_2'. Scan count 5, logical reads 11525, physical reads 1, read-ahead reads 11646, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:
CPU time = 593 ms, elapsed time = 1248 ms.

К сообщению приложен файл. Размер - 40Kb
13 фев 19, 13:53    [21808432]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36972
Тема индекса не раскрыта. Но, подозреваю, сервер не дурак, чтобы делать range scan по индексу и лукапиться в кластерник за недостающими полями.

Сообщение было отредактировано: 13 фев 19, 13:55
13 фев 19, 13:55    [21808436]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36972
Glebanski
YEAR and MONTH оказывается получше, чем прямое сравнение по датам

Ну да, 170к разных чтений гораздо лучше, чем 11к.
13 фев 19, 14:00    [21808440]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Glebanski
Member

Откуда: Msk ->NL
Сообщений: 308
Гавриленко Сергей Алексеевич,

Обычный индекс по полю datetime (да, дамп базы из 2005 года)
13 фев 19, 14:08    [21808455]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36972
Первый план ужасный.
Второй план лучше: чтений на порядок меньше, и, возможно, под вашу структуру он и идеален.

Хотите seek -- делайте индекс, который вам советует сервер. Хотите seek без изменения структуры -- сделайте forceseek и сравните кол-во чтений со вторым вариантом.
13 фев 19, 14:11    [21808462]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Владислав Колосов
Member

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

второй запрос будет вообще идеально работать, если построите кластерный по дате.
13 фев 19, 14:28    [21808494]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
daw
Member

Откуда: Муром -> Москва
Сообщений: 7381
Glebanski
Не то чтобы вопрос жизни и смерти, но концепция что SARGable, а что нет прям у меня на глазах рушится. Наверно давно планы не отлаживал или какой твиттер упустил.

стопудово пропустили. был такой твиттер про отличие index seek от index scan.
13 фев 19, 14:30    [21808500]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
daw
Glebanski
Не то чтобы вопрос жизни и смерти, но концепция что SARGable, а что нет прям у меня на глазах рушится. Наверно давно планы не отлаживал или какой твиттер упустил.

стопудово пропустили. был такой твиттер про отличие index seek от index scan.

и как связан ваш "комментарий" с вопросом?
13 фев 19, 14:35    [21808513]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
invm
Member

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

Добавьте к своим запросам option (maxdop 1) и сравните еще раз. Либо сравнивайте CPU time, а не elapsed.
К тому же, неплохо бы исключать затраты на передачу данных клиенту.
13 фев 19, 14:40    [21808522]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Glebanski
Member

Откуда: Msk ->NL
Сообщений: 308
invm,

Эффекта нет, да и это база на моем лэптопе.
Весь вопрос скорее в том, что может кто знает, почему SQL Server пытается через datepart насильно индекс попользовать.
Может быть какой программист подумал "а что это у нас клиенты жалуются, что MONTH и YEAR не используют индекс по дате? давай ка выкатим апдейт и покажем им, что мы умеем умно запросы парсить" :D
13 фев 19, 14:57    [21808548]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Glebanski
invm,

Эффекта нет, да и это база на моем лэптопе.
Весь вопрос скорее в том, что может кто знает, почему SQL Server пытается через datepart насильно индекс попользовать.
Может быть какой программист подумал "а что это у нас клиенты жалуются, что MONTH и YEAR не используют индекс по дате? давай ка выкатим апдейт и покажем им, что мы умеем умно запросы парсить" :D

а где тут datepart? MONTH и YEAR детерминистические функции, и их индекс может использовать...
13 фев 19, 15:04    [21808555]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
invm
Member

Откуда: Москва
Сообщений: 9349
Glebanski
Эффекта нет
Конечно нет. Это наглядно видно по CPU time в показанном вами результате.
Glebanski
да и это база на моем лэптопе.
В этом случае нету затрат на передачу данных клиенту?
Glebanski
Весь вопрос скорее в том, что может кто знает, почему SQL Server пытается через datepart насильно индекс попользовать.
Посмотрите на оценочное число строк для Index Scan и Clustered Index Scan.
13 фев 19, 15:11    [21808568]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7762
автор
Весь вопрос скорее в том, что может кто знает, почему SQL Server пытается через datepart насильно индекс попользовать


Меньше прогнозируемая стоимость.
13 фев 19, 16:26    [21808685]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Mike_za
Member

Откуда: Москва
Сообщений: 1176
TaPaK
daw
пропущено...

стопудово пропустили. был такой твиттер про отличие index seek от index scan.

и как связан ваш "комментарий" с вопросом?


дак разве автор не упомянул SARGable?
13 фев 19, 18:48    [21808863]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
TaPaK
Member

Откуда: Kiev
Сообщений: 6801
Mike_za
TaPaK
пропущено...

и как связан ваш "комментарий" с вопросом?


дак разве автор не упомянул SARGable?

это означает seek что ли?
13 фев 19, 18:48    [21808864]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Glebanski
Member

Откуда: Msk ->NL
Сообщений: 308
Есть теория, что планировщик, при виде Year и Month, полагает, что ему будет достаточно первых 3 байт из искомого поля для поиска и сравнения. И достать эти 3 байта из индекса выглядит как раз очень соблазнительной перспективой
13 фев 19, 19:27    [21808886]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Glebanski,

А вас ни на секунду не смущает что первый план ожидает 1 строку, хотя на самом деле их возвращается 54429? Это одна из частых ошибок оптимизатора, и будь у вас побольше строк и посложнее план вообще все бы встало надолго. А когда во ктором случае сервер понимает с чем реально имеет дело, то решает просто просканировать кластерный, что оказывается намного дешевле, судя по вашим же цифрам.

Вы короче два раза нагибаете сервер:
1. Сначала из-за YEAR and MONTH он не может оценить количество строк и строит ущербный план.
2. А потом "индекс был успешно заюзан". Успешно, это когда поиск по индексу, у вас скан. А почему? Потому что не SARGable!
13 фев 19, 21:46    [21808961]     Ответить | Цитировать Сообщить модератору
 Re: YEAR and MONTH оказывается получше, чем прямое сравнение по датам  [new]
Mike_za
Member

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

А что это означает?
13 фев 19, 23:08    [21808994]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить