Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Все доброе время суток.
Проблема такая,
запускаю процедуру, смотрю план выполнения основного запроса, вижу в нём что к одной и той же таблице идёт два вызова
1) основной, который был и раньше index seek
2) проверка, новая, (текущая дата должна находится между двумя значениями дат искомых экзмпляров) которая идёт через key look up

Сразу начало работать "бычтрее чем без проверки", что уже насторожило потому что я ещё никаких индексов не создавал.

Далее, моя мысль идёт просто и прямолинейно. Я думаю "надо создать индекс такой же как по котрому идёт Index Seek, только добавить туда две даты". План запроса начинает напоминать старый (до проверки на даты) и работать дольше.
Так же в плане вижу подсказку "создать индекс". Ради любопытства создаю, получаю чуть лучшее быстродействие (duration) но всё равно хуже чем БЕЗ индекса.

Собственно уже понимаю что если убрать индекс который использовал старый запрос без проверки на даты (или изменить его), то тоже можно было бы улучшить duration.

В чём тут проблема может быть?

Заранее спасибо.

К сообщению приложен файл. Размер - 6Kb
30 июл 13, 17:21    [14638932]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Могу ещё добавить что когда я создаю копию старого индкса добавив в него два поля с датами (не в include часть) начинается использоваться один индекс и Index scan
Второй индекс создаётся "только с датами" в основных полях (а всё остальное в include) и уже начинается Index Seek.

По факту эти условия крактически НЕ ограничивают выборку. Они "ограничительные" но почти все строки попадают под это условия и возвращаются. Сам результат ограничивается другими джойнами (в основном ФТС табличной функцией).
30 июл 13, 17:30    [14638979]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
параллелизм?
30 июл 13, 17:31    [14638987]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Ещё важный момент
В случае "без индексов" используется паралелизм, с индексами уже НЕТ и на фоне основных скриптов в плане показыватся 99% когда есть индекс предложенный СКЛ Сервером, а без индекса (несмотря на меньший duration) показывается 100%.
30 июл 13, 17:33    [14638993]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3752
1. статистику обновить
2. код с примером привести
30 июл 13, 17:41    [14639043]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
NIIIK
Ещё важный момент
В случае "без индексов" используется паралелизм, с индексами уже НЕТ и на фоне основных скриптов в плане показыватся 99% когда есть индекс предложенный СКЛ Сервером, а без индекса (несмотря на меньший duration) показывается 100%.

с параллелизмом запрос дороже чем без, больше процессорного времени уходит, хотя физически быстрее выполняется.
30 июл 13, 17:51    [14639090]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Ivan Durak
1. статистику обновить
2. код с примером привести


Если "статистику обновить" означает в свойства статистики по индексу поставить галочку "Update statistics for those columns" или что у индекса стоит своейство "автоматически обновлять..." - то обновлял. Другого не знаю, инлексы вновь созданные.

Читабельный код с примером привезти не могу. Процедура большая, с динамическим кодом и т. п.
По факту к основной таблице добавилось условие

from tMainTable t
where @currentDate between t.startDate and t.endDate
30 июл 13, 18:03    [14639140]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Мистер Хенки
NIIIK
Ещё важный момент
В случае "без индексов" используется паралелизм, с индексами уже НЕТ и на фоне основных скриптов в плане показыватся 99% когда есть индекс предложенный СКЛ Сервером, а без индекса (несмотря на меньший duration) показывается 100%.

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


Ну этот момент я понимаю, поэтому и сказал про него. Хотя мне важно сейчас "duration улучшить максимально".

Проблема, как мне кажется, в том что условия в where практически не ограничивают результат, а те джойны что ограничивают "потом" выполняются.
30 июл 13, 18:05    [14639146]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
NIIIK
Мистер Хенки
пропущено...

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


Ну этот момент я понимаю, поэтому и сказал про него. Хотя мне важно сейчас "duration улучшить максимально".

Проблема, как мне кажется, в том что условия в where практически не ограничивают результат, а те джойны что ограничивают "потом" выполняются.

без запроса, плана запроса и знания распределения данных можно только гадать. Но вообще поиск по покрывающему индексу будет работать быстрее всего на небольшом количестве результирующих записей.
30 июл 13, 18:09    [14639164]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3752
NIIIK
Мистер Хенки
пропущено...

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


Ну этот момент я понимаю, поэтому и сказал про него. Хотя мне важно сейчас "duration улучшить максимально".

Проблема, как мне кажется, в том что условия в where практически не ограничивают результат, а те джойны что ограничивают "потом" выполняются.

статистика предсказывает селективность выборки по дате достаточно высокую чтобы делать Seek а не скан. Она ошибается. Варианта два - либо статистика неверна, либо в принципе распределение таково что предсказать правильно невозможно.
p.s. Обновите статиcтику руками, спец. tsql команда для этого есть.
30 июл 13, 18:16    [14639185]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3752
NIIIK
Процедура большая, с динамическим кодом и т. п.

о, ну тут вообще все условия чтобы оптимизатор ошибся.
на крайняк скан можно захинтовать конечно.
30 июл 13, 18:19    [14639192]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
=)8)
Guest
NIIIK, а вот так - тоже нельзя:)?

К сообщению приложен файл. Размер - 29Kb
30 июл 13, 18:24    [14639210]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
NIIIK
Читабельный код с примером привезти не могу. Процедура большая, с динамическим кодом и т. п.
При чём тут размер процедуры и динамика?

Нужен же только код запроса и план, а не весь текст процедуры
30 июл 13, 19:09    [14639369]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Anonimize у меня почему-то нет.
Запустил ПРО весрию в Эвалюэйшен.

alexeyvg,
Выдрать то запрос я бы смог, хотелось бы его анонимизировать конечно, но он реаль "та ещё хрень".
Если в него в курите - это будет всё равно что вы за меня делаете работу (причём не быстро)
А суть проблемы я и излагаю "понятно"
1) есть изначально огроменный (сравнительно колхозный, но уже значительно лучше) запрос
2) в нём есть основная таблица
3) появляется дополнительное есловие по датам
4) пока поля с датами не включены в индекс - запрос работает быстрее (но стоимость его больше и с распаралеливанием)

Я как бы тоже не первый раз в жизне пишу запросы и вижу планы, хоть и не "супер гуру".
Если получится всю эту хрень анонимизировать - приатачу
30 июл 13, 22:13    [14639952]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
NIIIK
3) появляется дополнительное есловие по датам
4) пока поля с датами не включены в индекс - запрос работает быстрее (но стоимость его больше и с распаралеливанием)
Ну что, бывает...
У меня тоже часто такое, вообще без индексов тьаблица - работает как то запрос. Делаю индекс, вроде идеально всё - индекс покрывающий, знай себе выбирай записи по ПК - однако запрос становится неприемлимо медленным (и работает не на 24 ядрах, а на одном)

В общем это в каком то роде шманство, нужно читать планы и пытаться оптимизировать, в том числе убирая "правильные" индексы :-)
NIIIK
Если получится всю эту хрень анонимизировать
Можно сохранять планы в файл и менять имена в текстовом редакторе, это же просто XML.
31 июл 13, 01:41    [14640683]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
NIIIK
Anonimize у меня почему-то нет.
Запустил ПРО весрию в Эвалюэйшен.

alexeyvg,
Выдрать то запрос я бы смог, хотелось бы его анонимизировать конечно, но он реаль "та ещё хрень".
Если в него в курите - это будет всё равно что вы за меня делаете работу (причём не быстро)
А суть проблемы я и излагаю "понятно"
1) есть изначально огроменный (сравнительно колхозный, но уже значительно лучше) запрос
2) в нём есть основная таблица
3) появляется дополнительное есловие по датам
4) пока поля с датами не включены в индекс - запрос работает быстрее (но стоимость его больше и с распаралеливанием)

Я как бы тоже не первый раз в жизне пишу запросы и вижу планы, хоть и не "супер гуру".
Если получится всю эту хрень анонимизировать - приатачу
Не понятно в таком случае, а что вы от нас то хотите? Лечение по фотографии? Может у вас там есть другие джойны и условия из которых можно выжать больше оптимизации чем из этой проверки по датам.

С индексами стоимость плана становится меньше, следовательно сервер не рассматривает параллелный план и время выполнения увеличивается. Можете попробовать уменьшить "cost threshold for parallelism" (естественно не без последствий для других запросов), ну или использовать недокументированные хинты для принудительного включения параллелизма.
31 июл 13, 04:42    [14640821]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Mind,

Ну я же не зря стараюсь упростить, конкретизировать симптомы.
Я и к врачу когда хожу обычно приблизительно знаю что у меня хотя бы на уровне аллергия или ОРЗ.
Так и тут конкретизировал вопрос


Анонимайзер вболее поздних версиях появился. Прикольна штука.

К сообщению приложен файл (ExecutionPlans.zip - 38Kb) cкачать
31 июл 13, 17:08    [14644322]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31956
NIIIK,

А что это за расширение файла - queryanalysis, какой программой сохранили план?
31 июл 13, 17:31    [14644437]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Мистер Хенки
Member

Откуда: канализация
Сообщений: 6615
Интересный индекс seek на table11 для почти 2000000 записей (это на втором плане). Это принудительно задано, ошибка оптимизатора или действительно огромная таблица?
31 июл 13, 18:03    [14644578]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
дейсвтиетельно "огромная таблица".
Все хинты поубирал.

Тот индекс что на втором плане "рекомендуется" оптимизатором (или SSMS показывает я ХЗ) после того как создаю другой.

По факту эти все данные тащить НЕ надо было бы.

Представте, есть таблица "с большим количеством товаров/продуктов/..." а вы в поиске набрали "красный"
И по FTS уже остаётся около 20т. (а по факту меньше). Остальные условия которые выполняются в большенстве случаев.
31 июл 13, 18:11    [14644612]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
alexeyvg,

SQL Sentry Plan Explorer.

В целом действительно "эргономичнее" чем SSMS. У них по-моему ещё плагин был для SSMS.
31 июл 13, 18:13    [14644622]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Что за мега-хинты недокументированные для принудительного включения параллелизма?
31 июл 13, 18:21    [14644674]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
Гость333
Member

Откуда:
Сообщений: 3683
NIIIK
У них по-моему ещё плагин был для SSMS.

Плагин всего лишь добавляет пункт меню "View with SQL Sentry Plan Explorer", когда пользователь нажимает в SSMS правую кнопку мыши на плане выполнения. При выборе этого пункта меню запускается SQL Sentry Plan Explorer как отдельная программа.

NIIIK
Что за мега-хинты недокументированные для принудительного включения параллелизма?

OPTION(querytraceon 8649).
При этом надо учитывать, что выше параллелизма, заданного на сервере, не распараллелится. К примеру, на уровне сервере стоит maxdop = 1, а вы хотите распараллелить на 4 процессора. Тогда надо указать OPTION(maxdop 4, querytraceon 8649).
31 июл 13, 18:32    [14644740]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
NIIIK
Member

Откуда: Россия, Ростовская область, г. Таганрог
Сообщений: 1295
Гость333,

OPTION(querytraceon 8649)

нашёл, проверил, с ним опять быстре (на уровне как без индекса) визуально план "лучше чем без индекса" незначительно.

К сообщению приложен файл (015_executionPlan_Parallelism.zip - 20Kb) cкачать
31 июл 13, 18:48    [14644829]     Ответить | Цитировать Сообщить модератору
 Re: Index seek + key lookup работае быстрее  [new]
SomewhereSomehow
Member

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

Я бы начал разбираться вот с этого места:
Картинка с другого сайта.

Ошибка в оценке почти в 10 раз. Нужно выяснить, почему так и что скрывается за выражением: Table11.Column53 <= ScalarString46.
Кроме того, после этого идет потребляющий память Hash Join, который имеет свойство сливать на диск, в случае, если памяти для него выделили меньше чем надо. Если у вас 2012 сервер и в плане нет предупреждения, то спила нет, но если версия ниже, то включите профайлер, там событие Errors and Warnings -> Hash Warning, выполните запрос, и посмотрите, будут ли предупреждения.

В любом случае, эту ситуацию надо постараться исправить. Попробуйте выполнить простой запрос включив реальный план, будет ли такая же ошибка в оценке? (Вместо заменителей подставьте реальные объекты, конечно)
select Column21,Column23,Column24,Column25,Column27,Column36,Column41 from [Database2].[Schema1].[Table11] 
where Table11.Column53 <= ScalarString46

При этом, удостоверьтесь, что оптимизатор выбрал Index12.
Будет ли такая же ошибка? Если да, смотрите, что там со статистикой по этому индексу, посмотрите гистограмму, посчитайте примерно сколько по ней оптимизатор ожидает будет выбрано строк.

В первом плане, этот индекс не используется, оценка гораздо ближе к действительной, в том числе по этому, там имеет место быть параллелизм.
Если бы в плане с индексом оценка была не 169 272, а ближе к 1 000 000, т.е. к тому, что в реальности, то, возможно, оптимизатор из-за бОльшего числа строк принял бы решение о параллельном плане и без всяких флагов трассировки. В таком случае, вы бы, возможно, получили преимущества параллельного выполнения, избавились бы от спила и лукапа. Имхо, самый лучший вариант.

Ну и еще момент, я насчитал в диаграмме соединения аж 16 таблиц - возможно, имеет смысл разбить запрос на более мелкие части, сохраняя предварительные результаты во временных таблицах и работая уже с ними. также, в этом случае будет проще проводить анализ и выделять проблемную часть.
31 июл 13, 19:22    [14644976]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить