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

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

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

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

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

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

"ВЫБРАТЬ
            |    ВыгрузкаВБегучку.ДатаНачалаВыхода КАК ДатаНачалаВыхода,
            |    ВыгрузкаВБегучку.Длительность КАК Длительность,
            |    ВыгрузкаВБегучку.Активность КАК Активность,
            |    ВыгрузкаВБегучку.Текст КАК Текст,
            |    ВыгрузкаВБегучку.Картинка КАК Картинка,
            |    ВыгрузкаВБегучку.Выделение КАК Выделение,
            |    ВыгрузкаВБегучку.Рубрика КАК Рубрика,
            |    ВыгрузкаВБегучку.ПодРубрика КАК ПодРубрика,
            |    ВыгрузкаВБегучку.Номер КАК Номер,
            |    ВыгрузкаВБегучку.Регистратор КАК Объявление
            |ИЗ
            |    РегистрСведений.ВыгрузкаВБегучку КАК ВыгрузкаВБегучку
            |ГДЕ
            |    ВыгрузкаВБегучку.ДатаНачалаВыхода > &ДатаНачалаВыхода
            |    И ВыгрузкаВБегучку.ДатаНачалаВыхода < &ДатаОкончанияВыхода
            |
            |УПОРЯДОЧИТЬ ПО
            |    ДатаНачалаВыхода,
            |    Номер,
            |    Рубрика,
            |    ПодРубрика,
            |    Текст,
            |    Картинка,
            |    Выделение,
            |    Активность,
            |    Длительность
            |АВТОУПОРЯДОЧИВАНИЕ";
Это весь текст.

+ к сказанному приведу следующую цитату с одного форума...
"Как известно, в ДБФ-версии для индексирования numeric поля применяется выражение STR(поле, длина, точность).
К чему это приводит, тоже известно - идя по этому индексу, получаем, что  9 < -1 < 10"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(31) алгоритм поиска по индексу:

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


при такой схеме индексы не надо переформировывать при изменении строки, достаточно "ТОЧЕЧНОЕ" вмешательство

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

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

(34) Ладно, еще вопрос:

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

(35) Вот тут почитай:
http://ru.wikipedia.org/wiki/Двоичное_дерево

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(50) А нееет :)
Ты писал: "а ниче что в РС кластерный индекс?" :)

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