![]() |
#30 |
Участник
|
Цитата:
Сообщение от Alexius
![]() Варианты решения:
1. Создайте кластерный индекс по RecId 2. Добавьте в имеющейся индекс (DataAreaId, SalesDate, SalesTime) поле RecId и сделайте его кластерным 3. Попробуйте ограничить число полей в выборке и создайте покрывающий индекс 4. Создайте индекс напрямую на SQL (SalesDate, SalesTime, DataAreaId), если поможет, то можете в Аксапте встроить его проверку/создание в Classes / Application / dbSynchronize Варианты 2,3 помогут с очень высокой вероятностью, 1,4 - надо экспериментировать Сомнительно что кластерный индекс спасет. Если оптимизер решит сканировать таблицу, то помочь может вариант 2, но будет пиррова победа. Большое число полей в кластерном индексе плохо сказывается на производителности, плюс при таком условии ключ индекса не возрастает монотонно, что тоже плохо. По п.4 - можно и в Аксапте решить - был такой ключ командной строки CROSSCOMPANY - позволял ставить dataareaId не в начало индекса. |
|
Теги |
план запроса, производительность, статистика, запрос (query), индекс |
|
|