Цитата:
Сообщение от
Old
это только у меня, или кто-то решал эту проблему?
У Вас WHERE и ORDER BY указаны по группе полей (InventTransId, StatusReceipt, StatusIssue), которая ни одним штатным индексом не покрывается, так что это некоторый челлендж для оптимизатора. Планов исполнения Вы не привели, поэтому
предположительно в запросе без сортировки он подхватывает индекс TransIdIdx, отбирает проводки по лоту и далее эту выборку дофильтровывает по StatusReceipt, StatusIssue, а во втором запросе видит для себя дополнительную работу по сортировке и пытается упростить себе жизнь, отобрав уже отсортированные по StatusIssue ключи в StatusItemIdx и потом дофильтровав выборку по лоту. По идее, единичный лот обычно гораздо селективнее любой комбинации {StatusReceipt, StatusIssue} и выборка по нему предпочтительнее, но это уже относится к организации статистик вообще и к их аккуратности и актуальности конкретно в Вашей БД. В качестве workaround-а можно предложить как минимум два варианта:
- решение "в лоб": создать индекс по {InventTransId, StatusReceipt, StatusIssue}
- решение "a la DAX 2009": сделать индекс по лоту (TransIdIdx) кластерным, тогда он с большей вероятностью будет использоваться при указании номера лота, плюс много других соображений, в которые мы сейчас углубляться не будем. Мне этот вариант нравится больше