А селективность какая запроса, т.е. какое кол-во записей от общего числа в таблицах он возвращает ? Если высокая, то предлагаемый в ASA9 план получается эффективнее, зачем сначала сканить индексы, а потом значения с таблиц считывать.

Так же запустите ради интереса Consultant Index, что он скажет. Плюс посмотрите в графическом плане запроса расшифровку JH (Join Hash). Вполне возможно, что он делает внутренний Join по индексам таблицы tblOrderDetail.

Выбор использования временных таблиц "Work Table" зависит еще от выделенного размера кэша сервера, предполагаемого обьема обрабатываемых записей (в данном случае для ORDER BY) и значения опции MAX_WORK_TABLE_HASH_SIZE, указывающей, когда начинать их использовать.

Так же можно поиграться с калибровкой БД по скорости винта (ALTER SERVER CALIBRATE). Ну и рекомендую посмотреть в сторону кластерных индексов, например явно не помешает сделать кластерным FK-индекс таблицы TblOrderDetails (который на таблицу TblOrder).

P.S. А вообще план в ASA9 - понятие абсолютно динамическое и для разных ситуаций, обьема и содержания информации для одних и тех же запросов он будет разным. Хотя направлять его неявным образом в нужную сторону можно индексами и способами соединения таблиц в запросах (например на больших обьемах inner join и any будут вести себя скорее всего по разному).

авторКаким же образом в таком случае можно протестировать эффективность запросов для довольно таки большого приложения в базе данных с часто изменяющимся объемом информации?
Для ASA при составлении запросов, чтобы быть уверенным в нормальных планах запросов вне зависимости от обьемов и содержания данных я бы порекомендовал соблюдать несколько простых правил:
1. Правильная проектировка БД - соблюдение нормализации, тщательное продумывание связей таблиц и ключей. Например у Вас может быть оказалось бы эффективнее сделать в таблице TblOrder новое поле-автоинкремент ID и сделать его как Primary Key, существующие же поля в Primary Key описать как CONSTRAINT UNIQUE. А таблицу TblOrderDetails соединять по этому полю, убрав с нее существующие поля соединения.
2. Правильная связь таблиц в запросах. Основной Table Scan с уходом на Hash Join частенько как раз по этой причине. ASA9 достаточно эффективно разгребает и анализирует связи, даже может убирать из плана указанные в запросах таблицы, но реально не востребованные, если они служат только для связи между другими таблицами и есть возможность все связать и без лишней таблицы. Однако в случае множественных связей таблицы к таблицам, особенно с использованием фильтров по полям, не участвующих в внешних ключах оптимизатор может замяться и выбрать Table Scan или не самый подходящий индекс. Можно сказать чем легче и понятнее читается запрос, тем больше гарантий, что всегда будет самый эффективный план. Если запрос действительно сложный, то лучше всего в таких случаях не забывать об использовании временных таблиц.

Ну и я еще бы посоветовал начинать оптимизировать запросы не в момент их написания, а в тот момент, когда они начали тормозить. Смысла делать сразу индексы на таблицы, которые вроде бы должны помочь, то же нет. Очень много шансов, что кроме места в БД и тормозов при обновлении данных, они ничего больше не принесут. Оптимизировать лучше на реальных БД, при условии, что идут реальные тормоза. Тут как раз и пригодиться профайлер, который покажет, где и что тормозит. А дальше уже запрос в ISQL и работа с планом запросов. У меня где то на практике: 90% от медленных запросов - это Table Scan и Hash Join из за сложных связей таблиц и вьюверов в запросе, и только 10% - от отсутствия нужного индекса.

Реально могу сказать, что оптимизатор достаточно эффективен, я на нем гонял запросы, обращающиеся к таблицам с десятками миллионов записей под различными углами (фильтры, группировки, вложенные запросы и т.д.) и в принципе каждый раз соглашался с планом, предложенным ASA.

По поводу оптимизации можно еще почитать BOL, но лучше всего поэксперементировать - немного поупражнявшись с запросами и посмотрев, от чего и как получается план запросов, можно писать довольно предсказуемые по плану и эффективные запросы.

P.S. Селективность - это выборочность. То есть процент выборки записей от их общего количества. Чем выше селективность, тем значит больше записей будут обработаны.

Гм. Судя по всему не подводит. Я как всегда напутал названия терминов - имел ввиду избирательность, назвал селективностью :)