|
![]() |
#1 |
Участник
|
Народ! Есть результат! Интересный и положительный! Завтра на работе буду - опишу все подробно!
__________________
![]() --- Народу собралось - яблоку плюнуть негде! |
|
![]() |
#2 |
Участник
|
Спасибо. Ждем
|
|
![]() |
#3 |
Участник
|
Цитата:
Поспешил. Ложная тревога. -- В результате работы отчета формируются несколько запросов к базе данных. На один из них (не тот, который нужен, но очень был похож) я наткнулся и поспешил с выводами. Стал делать разбор и понял что ушел не туда. -- Итак топчемся на месте. Таблица CUSTINVOICETRANS, идет скан таблицы в запросе по полю DATAAREAID. Поле DATAAREAID входит в состав индексов построенных на этой таблице (индексы из стандартного функционала). Но при выполнении запроса все таки сваливается в TABLE SCAN. Если индекс I_064ITEMIDIDX(по полям DATAAREAID, ITEMID, INVOICEDATE) сделать кластерным - план запроса изменяется и становится более эффективным (стоимость плана 458 до, и 37 - после переделки индекса в качестве кластерного). -- Задача: избавиться от TABLE SCAN не изменяя индексов стандартного функционала. Вопрос остается открытым.
__________________
![]() --- Народу собралось - яблоку плюнуть негде! |
|