Помогите понять индексы MS SQL #621322

Позорище на мою голову. Есть РС "Контактная информация". Ну будем считать - просто табличка. Делаю запрос вида SELECT _Fld14845_RRRef, _Fld14846RRef FROM _InfoRg14844 T1 WITH(NOLOCK) WHERE (T1._Fld14846RRef = 0x94A0FD27BDAD5C8041F122244CD904B6) SQL использует индекс _InfoR14844_ByDims20173_RRS (в котором эти 2 поля, первое _Fld14846RRef), что правильно и логично. Делаю запрос вида SELECT _Fld14848, _Fld14846RRef FROM _InfoRg14844 T1 WITH(NOLOCK) WHERE (T1._Fld14846RRef = 0x94A0FD27BDAD5C8041F122244CD904B6) Поле _Fld14848 не входит ни в один индекс. SQL делает TableScan! Почему??? Моя не понимать. Статистику обновлял update statistics _InfoRg14844 WITH FULLSCAN, ALL

Что то не густо.

можно терминами 1С? если это типовой регистр КС.

Выбрать всю контактную информацию с типом "Адрес"

поле составного типа и индекс по нему, соответственно, тоже?

"Поле _Fld14848 не входит ни в один индекс" Поэтому и... Хотя... По идее должен быть index seek, а потом выборка...

Поле не составного типа. Индекс - составного типа (это поле и другие поля в составе сложных измерений регистра). p.s. Там есть индексы на все случаи жизни

выбери до кучи _Fld14845_RRRef,

Что "потому и"? Я же не ищу по полю _Fld14848

оптимизатор зачастую живет своей жизнью... понять и простить

Сделать возможными хинты в запросах 1С. А не понять и простить.

>Я же не ищу по полю _Fld14848 пофих... оно первое по выборке >Хотя... По идее должен быть index seek, а потом выборка... смотря например какого размера таблица

Тоесть?

а селективность индекса какая хоть ?

Большая таблица. Об этом говорит IndexSeek в первом случае.

>Сделать возможными хинты в запросах 1С кое-какие у тебя и так есть...

Момент.

если у тебя.. 100 уникальных значений на 200 тыщ записей, то скан и будет :)

31,72%

Я могу подумать почему, но лучше ты скажи сразу.

Селективность то причем тут? Результат запроса по количеству строк одинаков. Разные только - включена в выборку неиндексированная колонка или нет.

это предположение, хотя странно

>Разные только - включена в выборку неиндексированная колонка или нет. она не просто включена, а стоит первой

А в T-SQL у MS строковые условия не обязательно обрамлять кавычками?

Поменял. Все так же.

И какая разница то?

Это не строки. Это бинарные данные.

Индексируй остальные колонки, которые в селекте присутствуют

Индексировать ресурс Представление неограниченной длины, в котором может крыться Война и Мир, дабы преодолеть звуковой барьер (900 байт:) Интересно.

я про измерения говорил

Измерения все проиндексированны. 1С создала для них туеву хучу индексов в разной последовательности полей. Тут все хорошо?... Я выбираю ресурс Представление, и сразу TableScan. Почему???

а если руками индекс в запросе выбрать, через With(Index)

?

Конечно сработает. Nested Loops -> IndexSeek-> RID Lookup

Смотрит в табличку по RowID

Бугага Взял другое строковое поле, тоже не входящее в индекс, но уже ограниченной длины SELECT _Fld14849, _Fld14846RRef FROM _InfoRg14844 T1 WHERE (T1._Fld14846RRef = 0x94A0FD27BDAD5C8041F122244CD904B6) Тот же TableScan, но план запроса мне подсказывает внести его в индекс. Missing index (impact 79.6567).....

18 + В первом случае не надо прыгать от индекса к записи так как в первом все данные лежат в индексе. Во второс случае проще пройтись по таблице это будет быстрее, т.к. данные все равно считываются страницами

Насчет первого случая я уже понял.

В каком случае будет выгодней прыгать от индекса к записи? Когда в выборке будет мало записей?

Я не занудствую. Я пытаюсь понять.

Ок. Если я счаст добавлю кластерный индекс на поле Fld14846RRef - он мне по кластерному индексу пройдется и RID Lookup, или все равно выгодней TableScan?

Хотя нет, какой RID Lookup, мы и так уже на нужной записи при кластерном.

Ураааа. ClusteredIndexSeek

Хоть тут разобрался. Остался вопрос - когда выгоднее nonclustered index seek и RID lookup, нежели TableScan

Да судя по 18 у тебя треть записей соответствует индексу и получается очень накладно прыгать. Поэтому по моему в MS SQL 2005 ввели индексы с данными, что бы не прыгать.

44+ INCLUDE CREATE INDEX IXPostalCode_inc ON Employees(PostalCode) INCLUDE(LastName) 42 ну да все данные и хранятся в клястерном индексе

Немного не понимаю, кстати, КАК можно накладно прыгать. Если у тебя есть ROWID - это как адрес в памяти, либо смещение файла, доступ почти мгновенен. Или я не понимаю чего?

Сделать выборку, чтобы выбралось 20-30 записей из 3500?

Не совсем мгновенен. При скане все данные хранятся в кэше процессора, а прыгать приходится либо к медленной памяти если страница с данными подгружена, либо эту страницу с диска подгружать

Или это из за того, что надо прочитать 8 кбайт страницы все равно?

Но у тебя то в 31%

ФУУУУУХ

Плюс даже когда последовательно читаешь данные сказывается эффект использования DDR с двойным чтением

Изменил условие на WHERE (T1._Fld14846RRef = 0xAF80FC923034C1ED41A83A7B79C1C3E0) В выборке 31 запись IndexSeek и RID УРААААА

52 + а там разница может достигать 10 раз При последовательном чтении и скачкообразным

Мир вновь заиграл красками. Пойду поем.

Спасибо тебе.

За пост.

На здоровье!

*закладка*

TableScan выгоднее для небольших таблиц. Использующих одну или несколько страниц данных. Для таких таблиц индексы лучше вообще не создавать

3500 записей на РС Контактная информация - это как?

хз. надо страницами считать. складываем длинну всех колонок, умножаем на кол-во записей. и делим на 4096. получаем кол-во страниц. 3500 для КИ это много. в 1С маленькая таблица, это что то типа справочника организации, валюты и прочее

гыгыгыгы... у меня 1,5 ляма

вру. для взрослых версий 8К размер страницы. 4К это в экспрессе

можно еще так посмотреть DBCC SHOWCONTIG ('dbo._InfoRg14844')

Гы гы у меня было 60 лямов, а одновременно обновлялись по 4 ляма на прямых запросах с Merge

Дайте кто нибудь большую табличку!!

>3500 записей это и была "большая таблица"??

А что нагенерить Гуидов  и случайных чисел проблема?

Некошерно. Надо будет думать, как генерить, чтобы правдоподобно было.

рандом по КЛАДРу

Ну ушел я с той работы, а так зиповские файлы десятками МБ исчислялись.

у тебя тоже табле скан по 1.5 ляму записей?