Эта тема является продолжением http://www.1cpp.ru/forum/YaBB.pl?num=1176287559
(использование индексов)
Если кратко – то было установлено, что драйвер FoxPro не использует индексы 1С,
из за чего не наблюдается существенного ускорения при наложении фильтров.

Было экспериментально установлено, что использование
Collating Sequence=MACHINE ускоряет работу в среднем в 3-4 раза.
Рекомендация вошла в FAQ по прямым запросам.
Данная настройка у меня используется уже 3 месяца в живой базе –
ускорение подтверждаю, глюков не замечено.

Тем не менее.
Метод оптимизации по индексу обещает ускорение до 10 000 раз – с ускорением в 3 раза это как то не вяжется.
Также можно установить индекс по товару в регистре (например «Продажи», галочку у «Отбор движений») и сравнить время выполнения запроса с условием

WHERE $РегПродажи.Товар = :ВыбТовар 

Есть ли индекс, нет ли индекса – время выполнения не меняется.

Оптимизация(использование индеков) в FoxPro (продолжение)

В FoxPro как и в 1С допускается хранение индексов в файлах CDX.
CDX файл это не индекс , а «контейнер» хранящий несколько индексов по соответствующей таблице.

Русскоязычная статья  по оптимизации – http://www.foxclub.ru/articles/index.php?id=45
(допонительно кому нужно «Русский Help для Visual FoxPro» включая функции
http://www.foxclub.ru/rhproject/project/ )
Основная статья по оптимизации (к сожалению на англ.)
"Using Rushmore Query Optimization to Speed Data Access"
http://msdn2.microsoft.com/en-us/library/1f5d2sa3(VS.80).aspx

Наиболее важные моменты для оптимизации языка запросов.
Оптимизации поддаются предложения WHERE, JOIN, ORDER BY.

Создание базового Optimizable выражений
Основные оптимизируемые выражения могут быть одной из двух следующих форм :
eIndex relOp eExp
- или
eExpr relOp eIndex
Где
•      eIndex  - полностью соответствуют выражению в индексе.
•      eExpr   - является любое выражение и может включать переменные и поля от других, не связанных таблиц.
•      relOp только следующие реляционные операторы: <, >, =, <=, >=, <>, #, ==, or != Вы также можете использовать ISNULL( ) , BETWEEN( ) , or INLIST( ) функции (или их эквиваленты SQL, как IS NULL и т.д.).

Очень важно понять, когда запросы будут оптимизированы и, когда они не будут. Visual FoxPro оптимизирует поиск условий, найдя точное соответствие между левой части выражение фильтра и индекса.
Если условие является сложным(много условий на таблицу), то такое сложное условие также может быть оптимизировано.

Результат (оптимизация) при соединении выражений.

Basic Expression 1      Operator      Basic Expression 2      Query Result
Optimizable      AND      Optimizable      Fully Optimizable
Optimizable      OR      Optimizable      Fully Optimizable
Optimizable      AND      Not Optimizable      Partially Optimizable
Optimizable      OR      Not Optimizable      Not Optimizable
Not Optimizable      AND      Not Optimizable      Not Optimizable
Not Optimizable      OR      Not Optimizable      Not Optimizable
—      NOT      Optimizable      Fully Optimizable
—      NOT      Not Optimizable      Not Optimizable

Рекомендации – первое условие должно быть полностью оптимизируемым, второе – желательно.
При соединении нескольких таблиц – первой должна быть наиболее оптимизируемая таблица с соответствующими оптимизирующими выражениями.

Тест
Исходный запрос.
|

SELECT
	|   Жур.$ОбщийРеквизит.Фирма as Фирма ,
	|   Жур.iddoc,
	|   Жур.IDDocDef
	|FROM
	|   1sjourn as Жур
	|
	|WHERE
	|   Жур.Date BETWEEN :НачДата~~ AND :КонДата~~
	| "; 

Модифицированный

 |SELECT
	|Жур.$ОбщийРеквизит.Фирма as Фирма ,
	|Жур.iddoc,
	|Жур.IDDocDef,
	| DTOS(date)+time+iddoc  as Индекс
	|FROM
	|1sjourn as Жур
	|
	|		WHERE
	| DTOS(date)+time+iddoc BETWEEN (DTOS(:НачДата~~)+'		   ') AND (DTOS(:КонДата~~)+'ZZZZZZZZZZZZZZZ')
	|
	|ORDER BY  Индекс
    | "; 

Испытание в живой базе, выборка за 1 день.
Первый – 2.5 сек
Второй -  0.015
Разница – в 150 раз.

P.S.
Данное исследование потребовало от меня много сил и времени (читай денег) , если не трудно – при использовании упоминайте автора
в предыдущем случае (с Collating Sequence=MACHINE) этого не было

Также остались нерассмотренными сложные запросы с соединением
таблиц и с переменными динамическими условиями (требуется ручная настройка условий для использования индексов – оптимизация запроса) – если кто присоединится к изучению этого вопроса – будет здорово

Хотел прикрепить статью - но прав нету.

В 150 и 90 раз?  
1С перед каждым замером закрывалась/открывалась?

Ну на счет 150 и 90 я бы не сказал а вот на счет 50 это точно!
Вот только на счет сетки не пробовал, но в принципе можно будет и по сети спробовать.

Тут как-то не всё так однозначно.
Я помню твою прошлую проблему с кодировкой. Так вот у меня вообще не имеет значения стоит в строке подключения Рашн или Машин.
Потестировал у себя запрос, приведённый тобой выше по выборке из журнала документов (убрал из второго запроса сортировку и выборку поля "Индекс"). Вот результаты:

Цитата:

Итого:
1) на периоде в 1 день увеличение скорости в ~50 раз
2) на периоде в 1 год уменьшение скорости в ~1,2 раза
3) у меня время выполнения запроса не меняется при смене "Collating Sequence" с "RUSSIAN" на "Machine"

JohnyDeath писал(а) 13. Июля 2007 :: 11:54:


Насчет периодов - так и должно быть.
При периоде в год стоимость расчета функции превышает пользу от применения индекса.
Индексные выражения нужно применять только когда есть высокая селективность по индексу
(думаю что прикидочно - от 10 раз)

У меня цифры на периоде в год
1. Старый - 3.0 сек
2.Новый - 2.5 сек.      Но это наверно потому, что у вас селективность по году меньше.

Вообщем не дай бог их везде подряд применять

Насчет сортировки - нужно проверить через FoxPro.
Еще возможно дело в том - что есть  пара индексов в самых тяжелых таблицах - IDDOC в 1SJOURN например,
а также все ID в справочниках - которые не являются сложными строковыми выражениями.
Соответственно чтобы шла оптимизаци при JOIN по этим полям достаточно просто
проставить правильный "Collating Sequence" . Видимо отсюда и появилось ускорение в 3 раза.
Те запросы, которые не используют такие поля - соответственно не ускоряются.

Касательно остатков понятно.
а вот как быть с оборотами?
Там же даты нету.
Есть только IDDOC
по нем соединяться?