ReSQL.ru
     
powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / План запроса в АСА9
5 сообщений из 5, страница 1 из 1
План запроса в АСА9
    #34229135
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ggg_old
Участник
ASA 9.0.2.3320
Есть таблица, содержит несколько полей. Одно из полей - типа date. По этому полю построен индех. В таблице содержится чуть больше миллиона строк. Записей за каждый день от 3 до 6 тыс и эты цифра стабильна.
Есть простой запрос
select count(*) from gs_sessions2
where data_date='2006-08-06';

Сервер запущен с минимальным объемом памяти 8мб, что-бы исключить влияние кеша. Запрос выполняется первым после запуска сервера. Запрос выполняется сканированием таблицы. Статистика по таблице обновлена.
Выдержки из плана для объекта таблица:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
Table Scan Scan gs_sessions2 sequentially

Table reference
Table name  gs_sessions2
Estimated rows 1043979
Estimated pages 18168
Estimated pages in cache 1846
Estimated row size (bytes) 92
Page map yes
Buffer fetch yes
Relax cursor stability yes
Lock Isolation level 0

Node Statistics 
Estimates         Description
RowsReturned 1.044e+006 Number of rows returned
PercentTotalCost 99.833 Run time as a percent of total query time
RunTime 11.694 Time to compute the results
CPUTime 2.61    Time required by CPU 
DiskReadTime 9.084  Time to perform reads from disk
DiskWriteTime 0 Time to perform writes to disk
DiskRead  18168  Disk reads
DiskWrite 0 Disk writes

Subtree Statistics 
Estimates          Description
RowsReturned 1.044e+006 Number of rows returned
PercentTotalCost 99.833 Run time as a percent of total query time 
RunTime 11.694 Time to compute the results
CPUTime 2.61 Time required by CPU
DiskReadTime 9.084 Time to perform reads from disk
DiskWriteTime 0 Time to perform writes to disk
DiskRead  18168  Disk reads
DiskWrite 0 Disk writes

Predicate
gs_sessions2.data_date = 2006-08-06 : 0.18698% Statistics

Т.к меня сканирование не устаривает, ставлю хинт на использование индекса
select count(*) from gs_sessions2 with (index (ix_date) )
where data_date='2006-08-06';
План такой:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
Index Scan Scan gs_sessions2 using index ix_date

Table reference
Table name gs_sessions2
Estimated rows 1043979
Estimated pages 18168
Estimated pages in cache 1779
Estimated row size (bytes) 92
Page map yes
Buffer fetch no
Relax cursor stability no

Index
Index name ix_date
Clustered index no
Depth 3
Estimated leaf pages 2231

Scan
Selectivity 0.18698% Statistics
Direction forward
data_date = 2006-08-06 ASC

Node Statistics 
Estimates                Description 
RowsReturned 1952   Number of rows returned
PercentTotalCost 99.899 Run time as a percent of total query time
RunTime 19.371        Time to compute the results
CPUTime 0.005095    Time required by CPU
DiskReadTime 19.366 Time to perform reads from disk
DiskWriteTime 0        Time to perform writes to disk
DiskRead 1893.3        Disk reads
DiskWrite 0               Disk writes

Subtree Statistics  
Estimates                 Description 
RowsReturned  1952 Number of rows returned
PercentTotalCost 99.899 Run time as a percent of total query time
RunTime 19.371 Time to compute the results
CPUTime 0.005095 Time required by CPU
DiskReadTime 19.366 Time to perform reads from disk
DiskWriteTime 0        Time to perform writes to disk
DiskRead  1893.3  Disk reads
DiskWrite 0 Disk writes

Т.е насколько я понимаю, что в случае работы с индексом сервер произвел 1893 операций чтения с диска, а при сканировании 18168. Заметил, что если в запросе будет просто select *, то по умолчанию сервер выбирает индекс. В общем - сложное это дело оптимизатор АСА, логику его работы предугадать сложновато, и это вынуждает юзать хинты. Может я чего не понимаю?
...
Рейтинг: 0 / 0
27.12.2006, 21:00
| Ответить | Цитировать | Написать  
План запроса в АСА9
    #34229163
better
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
better
Гость
А если побаловаться с размером кеша что будет?
Я на asa10 баловался с изменением размера кеша и заметил, что индекс используется в если кеш большой.Те при маленьком кеше fullscan кеш больше таблицы - индекс.
...
Рейтинг: 0 / 0
27.12.2006, 21:31
| Ответить | Цитировать | Написать  
План запроса в АСА9
    #34229299
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
Здесь вмешивается железо. Чтение с диска последовательных секторов когда надо сделать полный скан таблицы происходит быстрее чем поиск очередного нужного сектора на диске и подчитывание его.

Обрати внимание на параметры RunTime и CPUTime - первый показывает общее время работы запроса, а второй время работы процессора над запросом. В случае полного скана RunTime чуть-чуть меньше чем в случае поиска с индексом (поэтому оптимизатор и выбирает полный скан). Но нагрузка на процессор в первом случае на порядки больше. А разница RunTime-CPUTime дает тебе DiskReadTime.

Резюме: убей существующий индекс ix_date и создай его заново, но уже кластерного типа. Потом сделай REORGANIZE TABLE gs_sessions2 INDEX ix_date. Теоретически это должно ускорить выборки с индексом. С этим конкретным индексом, конечно, и замедлить работу с другими индексами.

---
http://www.rusug.ru] Портал русскоязычной группы пользователей Sybase
...
Рейтинг: 0 / 0
28.12.2006, 01:20
| Ответить | Цитировать | Написать  
План запроса в АСА9
    #34229772
Фотография Ggg_old
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ggg_old
Участник
Увеличил кеш, и система стала цеплять индекс. Таки наличие некого минимального объема кеша очень важно для сервера при выборе стратегии доступа. Итого кеш 8,32Мь - сканирование, 128мб - индекс.
...
Рейтинг: 0 / 0
28.12.2006, 10:55
| Ответить | Цитировать | Написать  
План запроса в АСА9
    #34231213
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
White Owl
Участник
Ggg_oldУвеличил кеш, и система стала цеплять индекс. Таки наличие некого минимального объема кеша очень важно для сервера при выборе стратегии доступа. Итого кеш 8,32Мь - сканирование, 128мб - индекс.Дык! При наличии достаточного кеша влияние хард-драйва сводится к минимуму :)
Если посмотришь на план запроса сейчас, с большим кешем, то увидишь что при том же значении CPUTime=0.005095 (ну плюс-минус конечно) резко уменьшается DiskReadTime.
...
Рейтинг: 0 / 0
28.12.2006, 17:39
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / Sybase ASA, ASE, IQ [игнор отключен] [закрыт для гостей] / План запроса в АСА9
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]