Почему join запрос разбивается на подзапросы!?

[3oppo]

Цитата:

Сообщение от AndyD

Хм.
Но вы же привели код метода и указали, что он полный. А в этом коде используются только _rassetTable.AccountNum и _ledgerTrans.AccountNum.
Или опять о чем-то умолчали?

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

Цитата:

Сообщение от Wamr

Сам по себе очень интересный основной запрос, который выгребает все проводки от начала времен до какой-то даты, а потом по ним в цикле строится какой-то мап. Просто интересно, сколько он уже эксплуатируется и как за это время подросла базулька? И как Вы думаете, когда этот цикл будет исполняться не 4800 раз, а 10 тыс или 100тыс поможет оптимизация основного запроса?

Вот то-то и оно. Эксплуатируется 3 года, после «успешного внедрения» внедренцы получили свои денежки и свалили, а сей час пользователи стали жаловаться, что очень медленно отчеты формируется, да ещё и неправильно. Полез разбираться, и наткнулся на эту «корягу».

Цитата:

Сообщение от Wamr

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

Не подходит.

Цитата:

Сообщение от Wamr

Посмотрите, наконец, планы исполнения запроса в рабочем режиме и из QA, так как только план запроса скажет Вам ПОЧЕМУ различается время исполнения из QA и из аксапты (но не скажет почему различаются планы )

Что то пользу от плана я не совсем понял. Ну видно какие индексы использует и чё?!

Цитата:

Сообщение от Wamr

Вы привели точный текст запроса из профайлера или подсократили упоминание индексов в нем?

Абсолютно точный код, скопировал весь метод полностью. Удаление индексов из запроса всё таки даёт некоторый выигрыш но не очень значительный.