Позорище на мою голову.
Есть РС "Контактная информация". Ну будем считать - просто табличка. Делаю запрос вида

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) можно терминами 1С? если это типовой регистр КС.

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

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

"Поле _Fld14848 не входит ни в один индекс"

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

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

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

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

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

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

>Я же не ищу по полю _Fld14848

пофих... оно первое по выборке

>Хотя... По идее должен быть index seek, а потом выборка...

смотря например какого размера таблица

(7) Тоесть?

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

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

(10) >Сделать возможными хинты в запросах 1С

кое-какие у тебя и так есть...

(13) Момент.

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

(17) 31,72%

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

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

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

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

она не просто включена, а стоит первой

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

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

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

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

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

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

Интересно.

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

(29) Измерения все проиндексированны. 1С создала для них туеву хучу индексов в разной последовательности полей. Тут все хорошо?...

Я выбираю ресурс Представление, и сразу TableScan. Почему???

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

?

(31) Конечно сработает.

Nested Loops -> IndexSeek-> RID Lookup

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

Бугага

Взял другое строковое поле, тоже не входящее в индекс, но уже ограниченной длины

SELECT
_Fld14849,
_Fld14846RRef
FROM _InfoRg14844 T1
WHERE (T1._Fld14846RRef = 0x94A0FD27BDAD5C8041F122244CD904B6)

Тот же TableScan, но план запроса мне подсказывает внести его в индекс. Missing index (impact 79.6567).....

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

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

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

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

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

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

Ураааа. ClusteredIndexSeek

Хоть тут разобрался.

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

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

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

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

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

(46) http://rsdn.ru/article/db/yukonnew.xml#EXCAC
Не совсем мгновенен. При скане все данные хранятся в кэше процессора, а прыгать приходится либо к медленной памяти если страница с данными подгружена, либо эту страницу с диска подгружать

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

(47) Но у тебя то в (18) 31%

ФУУУУУХ

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

Изменил условие на

WHERE (T1._Fld14846RRef = 0xAF80FC923034C1ED41A83A7B79C1C3E0)

В выборке 31 запись

IndexSeek и RID

УРААААА

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

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

(54) Спасибо тебе.

За (36) пост.

На здоровье!

*закладка*

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

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

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

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

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

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

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

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

>3500 записей

это и была "большая таблица"??

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

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

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

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

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