1) Rushmore-оптимизация НЕ использует индексы, содержащие фильтры
2) Rushmore-оптимизация использует только те индексы, выражение которых ПОЛНОСТЬЮ совпадает с выражением, указанным в условии отбора.

Поскольку Ваш индекс имеет фильтр по NOT DELETED(), то этот индекс при оптимизации использовать вообще не будет ни при каких условиях.

Поскольку выражение индекса в принципе не совпадает с выражениями, использованными в директиве WHERE, то при оптимизации этот индекс использоваться не будет.

Чтобы оптимизировать выражение типа

where (date={^2006.07.01}) and (SP22893=' 25OF') and (kind='4') and (accid=' HQ') and (CURRID=' 3')

Нужно 5 отдельных индексов. По каждому полю в отдельности.

Если же хочется использовать индекс аналогичный приведенному, но без FOR-условия, то условие отбора должно ПОЛНОСТЬЮ совпадать с выражением индекса. Т.е. что-то вроде

WHERE DTOS(DATE)+SP22893+KIND+ACCID+SC0+SC1+SC2+SC3+SC4+CURRID = DTOS({^2006.07.01})+' 25OF'+'4'+' HQ'+' 3'

Ну, я там некорректно расставил константы. У тебя между (accid=' HQ') and (CURRID=' 3') надо вставить еще значения полей SC0+SC1+SC2+SC3+SC4 или модифицировать условие так, чтобы "лишние" поля оказались в конце.

WHERE DTOS(DATE)+SP22893+KIND+ACCID+ CURRID +SC0+SC1+SC2+SC3+SC4 = DTOS({^2006.07.01})+' 25OF'+'4'+' HQ'+' 3'

FoxPro может выполнять операции поиска по неполному совпадению ключа. Т.е. по первым символам. Такие операции также оптимизируются, но в этом случае надо изменить выражение индекса, т.е. переиндексировать таблицу

1С бух итогине выбирает данные и с таким запросом, причем тоже долго думает.
select date,accid, kind, CURRID,SP22893,SC0,SC1,SC2,SC3,SC4, sum(cast(sd as double)) as n1 from where (DTOS(DATE)+SP22893+KIND+ACCID+SC0+SC1+SC2+SC3+SC4+CURRID = DTOS({^2006.07.01})+' 25OF'+'4'+' HQ'+''+''+''+''+' 3') GROUP BY date,accid,kind,SP22893,CURRID,SC0,SC1,SC2,SC3,SC4
Я ведь и еще раз могу написать, то, что уже написал.

ВладимирМ1) Rushmore-оптимизация НЕ использует индексы, содержащие фильтры

Поскольку Ваш индекс имеет фильтр по NOT DELETED(), то этот индекс при оптимизации использовать вообще не будет ни при каких условиях.

А почему не выбирает данные, так это Вам виднее. У Вас поля SC0, SC1, ... имеют тип VarChar и при этом не заполнены? По сути, Вы написали такое условие:


Таким условиям хотя бы одна запись соответствует? Для FoxPro символ равенства и тождественного равенства (два знака равенства подряд) - не одно и то же.

Приведите длину символьных выражений к длине символьных полей.

Т.е. если поле SP22893 это Character(10), то символьная константа должна иметь 10 символов. Дополнить пробелами в конце.

Для поиска через AND это не имеет значения, поскольку поиск выполняется по первым символам, но при включении этой константы в выражение, количество концевых пробелов (общая длина) приобретает принципиальное значение.

Сравните:


Очевидно, что без добавления концевых пробелов сложение символьных строк будет работать некорректно.

Для добавления концевых пробелов можно использовать функцию PADR()


PS: Не надо приводить методы 1С. Они мне ни о чем не говорят. Т.е. приблизительно логику понять могу, но в данном случае необходимо знать точную технологию работы.

Написать-то можно, только на скорость выборки это никак не повлияет


Вместо вопросительных знаков поставьте нужную размерность соответсвующих полей.

Если предполагается, что надо найти записи для которых поля SC0+SC1+SC2+SC3+SC4 пустые, то можно так



Проблема в том, что индексы имеют фильтры. Это уже никак не обойти. Оптимизация невозможна в принципе. Если только не строить индексы самостоятельно.

Как эти индексы использует 1С вопрос к разработчикам 1С. Им виднее