order by тормозит

[Old]

    InventTrans inventTrans;
    Counter     counter;
    TimeOfDay   start;
    ;
    start = timenow();
    for (counter = 1; counter <= 10; counter ++)
        while select inventTrans
            order by statusIssue
            where inventTrans.inventTransId   == '1234567890'               &&
                  inventTrans.statusReceipt   == StatusReceipt::None        &&
                  inventTrans.statusIssue     >= StatusIssue::ReservOrdered &&
                  inventTrans.statusIssue     <= StatusIssue::OnOrder
        {
            info(inventTrans.ItemId);
        }
    info(int2str(timenow() - start));
    start = timenow();
    for (counter = 1; counter <= 10; counter ++)
        while select inventTrans
//            order by statusIssue
            where inventTrans.inventTransId   == '1234567890'               &&
                  inventTrans.statusReceipt   == StatusReceipt::None        &&
                  inventTrans.statusIssue     >= StatusIssue::ReservOrdered &&
                  inventTrans.statusIssue     <= StatusIssue::OnOrder
        {
            info(inventTrans.ItemId);
        }
    info(int2str(timenow() - start));

Info Сообщение (13:28:54) 10
Info Сообщение (13:28:54) 0

Господа, это только у меня, или кто-то решал эту проблему?
Запрос элементарный, проиндексировано по inventTransId.
Сортировка по другим полям тормозит еще больше.
Решение есть, но что-то здесь мне не нравитcя.

Ax3.0 SP3 KR3 SQL2005

[Vadik]

Цитата:

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

это только у меня, или кто-то решал эту проблему?

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

• решение "в лоб": создать индекс по {InventTransId, StatusReceipt, StatusIssue}
• решение "a la DAX 2009": сделать индекс по лоту (TransIdIdx) кластерным, тогда он с большей вероятностью будет использоваться при указании номера лота, плюс много других соображений, в которые мы сейчас углубляться не будем. Мне этот вариант нравится больше

[Old]

Index кластерный
Решение есть, но мне не нравится, что при элементарном проиндексированном по inventTransId запросе, сортировка по любому полю кроме inventTtransId, такие тормоза.

[Old]

А у Вас это наблюдается?
Производительность ведь в разы.

[Wamr]

при нормальных индексах и статистиках такого быть не должно.

[Alexius]

Можно попробовать отключить параллелизм на MS SQL.
В запросе установлен отбор проводок только с определенным лотом, а обычно их число для одного лота не превышает нескольких десятков. Если это так, то сортировка небольшого кол-ва записей не должна ощутимо влиять на производительность.

[gl00mie]

Мне кажется, не надо танцев с бубном - лучше посмотреть на запрос в том виде, как его получает СУБД: если с ним все в порядке, то посмтотреть на план запроса, подумать, почему он "не такой, как надо", и копать в эту сторону.