Индексирование полей типа "Дата" #376296

Всем привет, кого не видел :) Есть запрос, в котором имеется следующее условие |ГДЕ |    Рег.ДатаНачала > &ДатаНачала |    И Рег.ДатаНачала < &ДатаОкончания Вопрос. Использует ли 1С индексы в случае такого условия (понятно что при условии "=" индекс используется), и можно ли вообще как-то отслеживать используемые индексы?

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

Ага, спасибо, так и делаю уже.

Хм, документов 30000, разницы никакой :)

Ты запрос-то целиком покажи.

Раз уж пошла такая пьянка, есть кто подскажет - я правильно понимаю, что индекс на поле - это некая таблица с 2-мя колонками: "НомерСтроки", "Значение", в которой хранятся отсортированные значения из индексируемого поля основной таблицы, а также номера их строк. Сортировка производится при вставке/удалении элемента, поиск - методом бисекции. Ищется номер строки основной таблицы. Это мои фантазии, или в этом есть доля правды?

|АВТОУПОРЯДОЧИВАНИЕ"; Это весь текст. + к сказанному приведу следующую цитату с одного форума... "Как известно, в ДБФ-версии для индексирования numeric поля применяется выражение STR(поле, длина, точность). К чему это приводит, тоже известно - идя по этому индексу, получаем, что  9 < -1 < 10"

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

Типа полный перебор таблицы, вы про это?

По индексу будут отобраны необходимые номера строк. Но, за данными скулю придется лезть в таблицу. То самое "прыгать по закладкам". Эта-то процедура и съест весь выигрыш в скорости, если в выборку попала большая часть таблицы.

"по закладкам скачет" - не поясните, что это означает?

спасибо. только при малой селективности он и не будет "по закладкам скакать", будет использоваться сканирование.

Тоесть полного перебора нет. Ок, ну а если интервал выборки - один день? По поводу - это так?

"по закладкам скачет" = Bookmark Lookup. Прости, господи, за мой плохой английский...

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

А в каком тогда запросе будет выигрыш?

а что с чем сравниваем?

Запрос с условием больше/меньше на поле типа Дата, с индексом и без.

в общем случае с индексом быстрее, но индекс будет использоваться не всегда - в этих случаях скорость будет одинаковая.

Большой Зуб, ты мне скажи, я в прав?

Я вот и пытаюсь выяснить "не всегда" - это когда? :)

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

А хэш разве можно сравнивать на больше|меньше (поиск бисекцией, там это надо)?

это когда с результирующий набор запроса попадает более какого то процента всех записей таблицы (то есть если в условии запроса передан большой временной интервал). В этом слечае нет смысла определять по индексу "закладку" каждой записи, а потом по нему для каждой записи получать значения остальных полей - выгоднее сразу сканировать таблицу. Но есть например из миллиона записей возвращается одна - лучше по индексу получить ее адрес, а потом - значения остальных полей. Оптимизитор сам все определит, можешь не париться.

ой, там не хэш вовсе, потому что из него можно получить само значения.

Теперь ясно, спасибо!

Ладно - время будет - буду спец. литературу читать. Где - то видел, что индекс формируется на основе бинарного дерева, но вот представить себе такое - не могу :-)

А чего именно предстаить не можешь? Каждый символ индекса - веточка, от которой остальные символы-веточки растут :)

Ну, и прошел я "от корней, до самых кончиков" © (Head and Sholders). И что получил?

P.S. Я - тупой 1С-ник, не забываем..

Номер в строке таблицы получил, которая соответствует индексу :)

Номера на самых кончиках хранятся? А в средних узлах - диапазон (перечисление нескольких) номеров, соответствующих условию?

алгоритм поиска по индексу: 1 находим в корне дерева первый символ - 2 получаем следующий уровень 3 если уровень последний имеем номер строки в базе, нет - п.1 при такой схеме индексы не надо переформировывать при изменении строки, достаточно "ТОЧЕЧНОЕ" вмешательство

На сколько я понимаю, в средних узлах ничего не хранится. В смысле, никаких диапазонов строк там нет.

и не может храниться, по тому как строки не храняться диапазонами :)

Ладно, еще вопрос: У меня есть Число. Оно что, преобразуется в строку и посимвольно помещается в дерево индекса?

Вот тут почитай:

Почитал. И все равно не понял, чем поиск/вставка элемента в двоичном дереве отличается от таблицы . Это же фактически одно и тоже?

это зависит от реализации, но обычно дерево строиться byte, то есть и строка и число рассмативаються как одинаковый тип бинари, хотя есть и строковые индексы

Сидим тут, за теорию перетираем... А у людей, вот, глобальные проблемы: :)

а ниче что в РС кластерный индекс?

Поясни свою мысль?

Просто у меня стойкая психологическое неприятие к деревьям после неудачной попытки реализовать B-дерево на Дельфи. :-)

>> Но, за данными скулю придется лезть в таблицу. Если используется кластреный индекс, то данные в этой же таблице

На поле ВыгрузкаВБегучку.ДатаНачалаВыхода построен кластерный индекс? Интересно, почему я в это не верю?

ну автор умлочал о том чем является ДатаНачалаВыхода Но если взять во внимание фразу "понятно что при условии "=" индекс используется", то можно сказать, что это измерение

а не вру - нельзя сказать :)

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

он по умолчанию строится по всем измерениям

Так мы понятия не имеем, в каком порядке у автора идут измерения. И где именно это измерение находтся в индексе. Очень большая вероятность, что не на первом месте.

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

лень было вдаваться в детали ;)