v8: Опять использование индексов #660457

Простейший запрос: ВЫБРАТЬ    РеализацияТоваровУслугТовары.Ссылка.Организация,    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары    РегистрНакопления.ТоварыОрганизаций КАК ТоварыОрганизаций 2 запрос дает Clustered Index Scan по индексу: _Accum20481_ByPeriod_TRN, хотя в него не входит ни СерияНоменклатуры ни Организация из регистра накопления. Как так?! Вот план запроса: StmtText     Hash Match(Right Semi Join, HASH:([T2].[_Q_000_F_000RRef], [T2].[_Q_000_F_001RRef])=([T1].[_Fld20482RRef], [T1].[_Fld20486RRef]), RESIDUAL:([Database].[dbo].[_AccumRg20481].[_Fld20482RRef] as [T1].[_Fld20482RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_000RRef] as [T2].[_Q_000_F_000RRef] AND [Database].[dbo].[_AccumRg20481].[_Fld20486RRef] as [T1].[_Fld20486RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_001RRef] as [T2].[_Q_000_F_001RRef]))

Простейший запрос: ВЫБРАТЬ    РеализацияТоваровУслугТовары.Ссылка.Организация,    Документ.РеализацияТоваровУслуг.Товары КАК РеализацияТоваровУслугТовары    РегистрНакопления.ТоварыОрганизаций КАК ТоварыОрганизаций 2 запрос дает Clustered Index Scan по индексу: _Accum20481_ByPeriod_TRN, хотя в него не входит ни СерияНоменклатуры ни Организация из регистра накопления. Как так?! Вот план запроса: StmtText     Hash Match(Right Semi Join, HASH:([T2].[_Q_000_F_000RRef], [T2].[_Q_000_F_001RRef])=([T1].[_Fld20482RRef], [T1].[_Fld20486RRef]), RESIDUAL:([Database].[dbo].[_AccumRg20481].[_Fld20482RRef] as [T1].[_Fld20482RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_000RRef] as [T2].[_Q_000_F_000RRef] AND [Database].[dbo].[_AccumRg20481].[_Fld20486RRef] as [T1].[_Fld20486RRef]=[tempdb].[dbo].[#tt2].[_Q_000_F_001RRef] as [T2].[_Q_000_F_001RRef]))

ты посмотри, во что (1,2) в (Выбрать 1,2 из ВТ) превращается...

там трэш

Какая разница?

exec sp_executesql N'SELECT FROM _AccumRg20481 T1 WITH(NOLOCK) WHERE EXISTS(SELECT 1 FROM #tt2 T2 WITH(NOLOCK) WHERE (T1._Fld20482RRef = T2._Q_000_F_000RRef) AND (T1._Fld20486RRef = T2._Q_000_F_001RRef))',N' numeric',1

хех, надо на 18 релизе глянуть. они же написали что наоптимизировали чего то там.

какая разница, какой релиз. Речь про SQL

ты чуешь коррелированный запрос

Я даже слова такого не знаю.

кластеред индекс скан = тэйбл скан

короче, замени на внутреннее соединение

Счегобы?

в данном случае это быстрее

индекс содержит все измерения

Нет

ведь скан, а не сиик

Именно это и удивляет.

Скан индекса, а не таблицы.

как это не содержит, врешь

Да, прикольно... Может, оптимизатор запросов БД не обращает внимания на выбираемые поля?

Период, Регистратор, НомерСтроки

Да не поэтому, а потому что он КЛАСТЕРНЫЙ - это и есть физ. записи в таблицах

А порядок измерений в регистре какой? И какие измерения индексированы дополнительно?

это для обхода коррелированного запроса, но сугубо имхо

+1

Нет

не

В кластерном данные - сразу, но только тех полей, которые в нем.

Это копия, а не ссылка.

Вложенные в терминологии 1С?

там exist используется

это в обычном индексе

да, но он все равно вызывается для каждой строки внешнего запроса (т.е. таб. регистра)

Кластерный индекс, это не индекс, а физ порядок

Кластерный индекс вроде все поля содержит же. Те, по поля по которым строится - порядок определяют.

Четовы меня смутили. Пойду почитаю про кластерный

в случае с Exist работает быстрее чем внутреннее соединение

эксистс - это тупо приближенно "селект топ 1"

ведь что есть внутреннее соединение - nested lookup, и вложенный тоже самое

не сомвем

Тю. Я думал, вопрос был в том, почему не используется подходящий индекс, вместо скана таблицы.

пусть автор ответит, быстрее, или нет :)

на 2000 во времена 77 точно быстрее было. сам проверял

Все, извиняюсь, кластерный индекс содержит данные.

Но план запроса все равно это не объясняет.

и что не понятно с учетом

Тааааак

sql построил хэш по 2-м полям и давай сканировать таблицу, но сканировать упорядоченно по кластерному индексу, так?

момент

вообще, конечно, не хватает возможности лепить свои составные индексы

Я не могу добиться TableScan-а

Чтобы понять

Как только в таблице имеется кластерный индекс, IAM более не используется для доступа к данным. IAM не исчезает вообще, но используется только для сопровождения таблицы как объекта в базе данных. Страницы данных взаимосвязаны и данные в них находятся в соответствии с кластерным индексом. Если выполнить запрос SELECT * FROM Customers без каких-либо условий WHERE, то система выполнить сканирование таблицы с использованием кластерного индекса. Эта операция очень похожа на простое сканирование таблицы. Главное различие между сканированием по кластерному индексу то, что результат сканирования вернется в порядке сортировки по кластерному индексу.

Все, понял, разобрался. Ascent-у респект и уважуха.

а ?

Я на Exist забил.

Тады точно SAP и другие помрут ))))

Вернемся к нашим песням. Смотрим типовые - на всех регистрах стоит индексированное измерение "Номенклатура", но неиндексированное "Серия". Логично. Но у меня есть регистр, который имеет измерение "Номенклатура" и "СерияНоменклатуры" (которое заполнено гораздо чаще чем в типовом случае). На данный момент индексированна "Номенклатура", но почти во всех запросах к регистру в условиях есть Номенклатура и Серия. Запросы скорее всего выполняют index seek nonclustered по индексу номенклатуры, а затем KeylookUp по физ. таблице по Серии. Если я добавлю индекс по серии - я не уверен, что оптимизатор выберет индекс по серии (но счаст попробую) и уверен, что запись будет медленней. И, как вариант - снять индекс с Номенклатуры и поставить на Серию. Что думаете?

Ладно, другой вопрос - почему в Типовых Серия не индексированна?

потому что типовой механизм индексирования не дает делать нормально составные индексы

а по алгоиртмам выбирается номенклатура + серия

Ну и что.

Вообще странно все.

Выбираю по серии и номенклатуре. Индексированна номенклатура - Clastered Index Scan Индексированна Серия - Index Seek+Lookup Индексированна Серия и Номенклатура - Index Seek (по индексу Серии)+Lookup

Почему в 1 случае SQL делает Index Scan, ведь у него индекс есть по номенклатуре!

Счаст попробую Первый случай, но отбирать буду только по номенклатуре, а в выборку включу Серию, Index Scan он мне сделает, или Index Seek по номенклатуре...

1. оптимизатор решил, что использовать индекс по номенклатуре неоптимально, попробуй статистику обновить 2 и 3 - одинаково по сути, так как правильных составных индексов нету. но никто не мешает навешивать свои составные индексы (до реструктуризиции, правда)

Индексированна Серия. И ищем по Серии и Номенклатуре. Лишние lookup-ы будут только там, где серия пустая, зачем тут составной индекс (в индекс включать Номенклатуру).

?

Пардон, спешу добавить.... И мы не просто ищем серию  и номенклатуру, но мы еще и Количество их берем :-)

а оптимизатор об этом знает? какой % записей с пустой?

вообще - индексирована серия - значит составной индекс на серию, период, регистратор, номер строки.... - оптимизатор думает, что ну его нафиг, погляжу ка я всю таблицу...

Я не про то. Я про то, что Вот ищем мы Номенклатура       Серия Лада               Калина SQL найдет по индексу "Калина" идентификатор строки и слазит в таблицу проверить Лада это или нет. И заодно вытащит Количество. Все норм. Однозначно надо лезть в таблицу за количеством. Все норм. Вот ищем мы Номенклатура       Серия SQL найдет по индексу "ПустаяСерия" идентификатор строки и слазит в таблицу проверить Жигулиэто или нет.  А это не Жигули, а Камаз. Неудача. Тут бы составной индекс и пригодился.

ms sql 2008 r2 пока так не думает.

Просто таких пустых серий У МЕНЯ будет мало. А вот типовые конфы универсальны, учет может быть и без серий, поэтому Серия и не индексированна.

Или нет?

Clastered Index Scan, блин.

Серию убираю, только номенклатура в Выборке - Index Seek без Lookup-а, но это то понятно.

сделай свой индекс ТОЛЬКО по серии, будет отбирать по нему

Это и работает.

Для Серии - работает. Для Номенклатуры - нет. Статистику - обновлял.

Выбираю по серии и номенклатуре. 1) Индексированна номенклатура - Clastered Index Scan 2) Индексированна Серия - Index Seek+Lookup 3) Индексированна Серия и Номенклатура - Index Seek (по индексу Серии)+Lookup 1 случай, отбирать буду только по номенклатуре, а в выборку включаю Серию. Хочу IndexSeek + Lookup, получаю Clastered Index Scan (Table Scan) по факту.

т.е. не галочки в 1с, а именно руками созданные индексы?

Нет, галочки.

Предлагаешь создать отдельный некластерный индекс только по полю Номенклатура, в SQL ?

галочки в 1с не рулят

рестартани скуль, если есть возможность, и: SELECT  TOP 10 FROM        sys.dm_db_missing_index_groups g INNER JOIN    sys.dm_db_missing_index_group_stats s       ON s.group_handle = g.index_group_handle INNER JOIN    sys.dm_db_missing_index_details d       ON d.index_handle = g.index_handle ORDER BY [Total Cost] DESC;

ну и отбор по имени таблицы

это после пары десятков своих запросов

Нет возможности пока. Будет ближе к ночи.

СОздал чистый индекс по номенклатуре, не использует его никак, использует старый индекс с Регистратором и Периодом, и.т.д. Статистику обновил, что еще надо сделать?

Ооо, снесу старый :-)

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

И Clastered Index Scan, когда в выборке добавляю еще и Серию, пичаль.

Ладно, пойду поем, а ночью, когда никто не видит, буду ставить опыты.

Я конечно догадываюсь, что дело в селективности, но вроде номенклатура достаточно уникальна, надо глянуть.

Фсе, отбой. Дело было в селективности.

Номенклатура была часто встречающаяся в регистре - и поэтому выбирался Index Scan, а потом уж отбор по серии - и в выборке у меня было мало записей, а когда отключил отбор по серии и тупо ее в выборке выводил - уже не обратил внимания на то, что там дофига записей.