День добрый.

Вот есть некоторые запросы к БД (1: и 2:( двумя запросами) ), есть статистика ( может она конечно несколько и не корректна из за того что некоторые данные в кеше осели ), но... чего то я не опредлюсь каким пользоваться... По цифрам вроде видно что двумя ( 2.a и 2.b ) запрсами данные выбираются быстрее только не понятно почему. В частности вот видно что в 2.a и в 2.b индексы разные пользуются - 2.a - не кластерный а в 2.b кластерный. И по чему первый запрос так долго работает.

1:


QUERY PLAN FOR STATEMENT 1 (at line 1).


STEP 1
The type of query is SELECT (into Worktable1).
GROUP BY
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.

FROM TABLE
Traffic
Nested iteration.
Index : TrafficFKMoment
Forward scan.
Positioning by key.
Keys are:
Moment ASC
Using I/O Size 16 Kbytes for index leaf pages.
With MRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.

STEP 2
The type of query is SELECT.

FROM TABLE
Worktable1.
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
....
Table: Traffic scan count 1, logical reads: (regular=185895 apf=0 total=185895), physical reads: (regular=15 apf=24736 total=24751), apf IOs used=24694
Table: Worktable1 scan count 1, logical reads: (regular=2099 apf=0 total=2099), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0

Execution Time 159.
SQL Server cpu time: 15900 ms. SQL Server elapsed time: 39320 ms.

(517 rows affected)


2.a:

STEP 1
The type of query is SELECT (into Worktable1).
GROUP BY
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.

FROM TABLE
Traffic
Nested iteration.
Index : TrafficFKMoment
Forward scan.
Positioning by key.
Keys are:
Moment ASC
Using I/O Size 16 Kbytes for index leaf pages.
With MRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.

STEP 2
The type of query is SELECT.

FROM TABLE
Worktable1.
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
...
Table: Traffic scan count 1, logical reads: (regular=185895 apf=0 total=185895), physical reads: (regular=402 apf=27537 total=27939), apf IOs used=27536
Table: Worktable1 scan count 1, logical reads: (regular=1013 apf=0 total=1013), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0

Execution Time 66.
SQL Server cpu time: 6600 ms. SQL Server elapsed time: 105080 ms.


-- выбираем второю половину данных...
2.b:

STEP 1
The type of query is SELECT (into Worktable1).
GROUP BY
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.

FROM TABLE
Traffic
Nested iteration.
Index : XIF764Traffic
Forward scan.
Positioning by key.
Keys are:
SourceAccID ASC
Using I/O Size 16 Kbytes for index leaf pages.
With MRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 4 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.

STEP 2
The type of query is SELECT.

FROM TABLE
Worktable1.
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

Parse and Compile Time 0.
SQL Server cpu time: 0 ms.
...
Table: Traffic scan count 1, logical reads: (regular=42179 apf=0 total=42179), physical reads: (regular=25841 apf=789 total=26630), apf IOs used=697
Table: Worktable1 scan count 1, logical reads: (regular=13778 apf=0 total=13778), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0

Execution Time 11.
SQL Server cpu time: 1100 ms. SQL Server elapsed time: 159583 ms.

P.S.

ASE 12.5.1

MasterZivВ первом запросе вот это странно :

Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

MRU может и хорошо, но вот 16K IO для data pages странновато
выглядит. Потому как ваш индекс не кластерный, и N (==4 у вас) подряд идущих страниц могут не быть последовательными по полю Moment.
Т.е. читается первая полезная страница и с ней еще 3. А используется только
первая, а поскольку MRU, то они тут же затираются и потом все равно будут читаться снова. Итог -- IO в четыре раза (на самом деле немного меньше) больше, чем надо.

Я бы попробовал заставить его на уровне таблицы читать по минимуму (4К же у вас страницы ?? ).


Да, страницы 4 k. Это вообще ( iosize для таблицы ) куда смотреть ?



А на счет что быстрее -- ну смотрите сами, у вас 1 и 2a абсолютно идентичные запросы. А во втором случае вы к нему добавляете еще один, 2b. как это может быть быстрее ? Никак.

Я вот просто 'Execution Time' у всех запросов посчитал, и сумма 2.a и 2.b меньше чем у первого запроса.... Хотя если верить 'Table: Traffic scan count 1, logical reads: (regular=185895 apf=0 total=185895' и 1 и 2.a действительно читают одинаковое количество данных, при том что к 2.a добавляетися и 2.b....

Еще вот интересно не из за этих ли:
конструкций у первого запроса время на выполнение больше получилось ?

про использование кластерного индекса в 2.b я прогнал....

MasterZiv Так кажется.


STEP 1
The type of query is SELECT (into Worktable1).
GROUP BY
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.
Evaluate Grouped SUM OR AVERAGE AGGREGATE.

FROM TABLE
Traffic
Nested iteration.
Index : TrafficFKMoment
Forward scan.
Positioning by key.
Keys are:
Moment ASC
Using I/O Size 4 Kbytes for index leaf pages.
With MRU Buffer Replacement Strategy for index leaf pages.
Using I/O Size 4 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.
TO TABLE
Worktable1.

STEP 2
The type of query is SELECT.

FROM TABLE
Worktable1.
Nested iteration.
Table Scan.
Forward scan.
Positioning at start of table.
Using I/O Size 16 Kbytes for data pages.
With MRU Buffer Replacement Strategy for data pages.

....
Table: Traffic scan count 1, logical reads: (regular=185895 apf=0 total=185895), physical reads: (regular=59243 apf=19631 total=78874), apf IOs used=19631
Table: Worktable1 scan count 1, logical reads: (regular=3270 apf=0 total=3270), physical reads: (regular=0 apf=0 total=0), apf IOs used=0
Total writes for this command: 0

Execution Time 194.
SQL Server cpu time: 19400 ms. SQL Server elapsed time: 76616 ms.


в добавок к prefetch'у пришлось еще и индекс к такому запросу гвоздями прибивать,
если явно не указать index TrafficFKMoment, но указать prefeth 4, пользовался вообще какой то левый индекс.


physical reads: (regular=59243 apf=19631 total=78874)

Вот у этих данных размерность в блоках в которых ведется чтение ?

тоесть `78874 * 4` vs `24751 * 16` сравнивать ?

MasterZiv g613Вот у этих данных размерность в блоках в которых ведется чтение ?

тоесть `78874 * 4` vs `24751 * 16` сравнивать ?

Да нет вроде. А время уменьшилось ?

Ну если на глаз то они примерно одинаково выполняются, а по цифрам с iosize 16k вроде быстрее...

В общем остановился на первом варианте. Только пришлось пересмотреть политику, до этого предполагалось, что та статистика будет отдаваться через веб интерфейс в онлайне... Теперь в онлайне только запрос на получение статистики, а обработка этого запроса по мере разгрузки сервера...

Вообще в начальном запросе больше интересовало влияние конструкций
на производительность, ну если говорите не стоит внимания на это обращать тады, оставлю как есть. Сенькс.