|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
Привет всем! кто-нибудь умеет оптимизировать запросы с GROUP BY clause? Например заставить их использовать индексы, построенные по группируемым полям, или группировать записи без сортировки (т.е. внутренний селект делает нужный ORDER BY, а внешний тупо группирует то, что выдал внутренний). может оракловые хинты какие-нить есть? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 13:30 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
А поконкретнее ? Может быть, нужно select ... from (select ... from ... group by ...) order by ... ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 13:53 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
неправильная постановка вопроса - любой запрос надо (или можно) оптимизировать независимо от наличия group by. На этапе группировки данные уже выбраны из таблиц, поэтому оптимизировать план доступа к данным на этом этапе смысла не имеет (возможно там нужен FTS). Поэтому надо оптимизировать либо сортировку (sort_area_size, temporary segment и т.д.) либо FTS, если его нельзя избежать. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 13:56 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
поконкретнее: есть запрос с group by по нескольким полям. есть индекс на эти поля. но он почему-то не используется :( как одно из решений хорошо подошла бы "тупая" группировка (если такая вообще есть) select /*+ some-hint-to-group-without-sortig */ a, b, c, count(*) from ( select a, b, c from ent_table order by a, b, c ) group by a, b, c ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 13:59 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
что такое FTS? и как научить sort group by использовать индекс? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 14:02 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
select a, b, c, count(*) from ent_table group by a, b, c вот и все (зачем тут вообще подзапрос и явная сортировка?). Как раз случай FTS - full table scan. Так что никакие индексы тут не помогут. Как оптимизировать - смотри мой постинг выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 14:30 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
select a, b, c, count(*) from ent_table group by a, b, c план запроса: SELECT STATEMENT, GOAL = CHOOSE +--SORT GROUP BY +--+--TABLE ACCESS FULL ent_table дело в том, что табилца очень большая и сортировка для group by происходит очень долго. почему эта самая сортировка не умеет использовать индекс на a, b, c ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 14:37 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
Подумай сам - сколько строк в таблице тебе надо прочитать, чтобы составить любую группу по этой таблице - очевидно, что ВСЕ строки. Как же тебе в этом помогут индексы? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 14:45 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
А колонки - это именно колонки, или какие-то функции от колонок ? А колонки в индексе в том же порядке, как и в груп бае? Вообще-то, должен использоваться index full scan. Ну или пробуйте select /*+ rule*/ select /*+ index(<table или alias> <index>)*/ ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 14:53 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
.dba, если есть индекс по группируемым полям, то в теории всю таблицу прочитывать не надо. Например, что б в телефонной книге "сгруппировать" всех Ивановых (например count(*) для них посчитать) вовсе не обязательно всю книгу прочитать, достаточно открыть ее там откуда начинаются Ивановы и читать пока они не закончатся. ora600, я тоже всегда думал, что используется! оказывается нет :( Ваши хинты не помогли... ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:03 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
ой, забыл. Ора, да. это действительно реальные колонки. и на таблиице по ним построен индекс (в том же количестве и порядке) ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:05 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
>.dba, если есть индекс по группируемым полям, то в >теории всю таблицу прочитывать не надо. Например, что >б в телефонной книге "сгруппировать" всех Ивановых >(например count(*) для них посчитать) вовсе не >обязательно всю книгу прочитать, достаточно открыть ее >там откуда начинаются Ивановы и читать пока они не >закончатся. Ну вот вы сами себе и ответили :-). Для того чтоб использовался индекс надо сказать Код: plaintext
... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:09 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
а где у вас в запросе сказано, что сгруппировать всех Ивановых? По-моему, скорее всех "Сидоровых, Петровых, Ивановых и прочих кого найдешь". У вас индекс построен как (a, b, c) ? И если так, то сколько еще есть других полей в таблице, которые не используются в данном запросе? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:11 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
дба, ивановы это для примера того, как при группировке можно использовать индекс. то что в моем слечае full scan по таблице пройдет это я прекрасно понимаю. Но full scan и сортировка для группирования по времени довольно сильно отличаются. опять же на примере тел. книги: что б посчитать count(*) для всех фамилий вым нужно будет прочитать всю книгу один раз листая страницы по порядку (фамиилии же упорядочены), а что б посчитать count(*) по той же книге, но для названий улиц у вас уйдет на порядок больше времени... киллд, да индекс именно на (a, b, c) кроме них в таблице еще 2 поля. мне все больше начинает казаться, что при группировке индекс не используется в принципе :( ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:23 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
Эти колонки NOT NULL ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:30 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
>то что в моем слечае full scan по таблице пройдет это я >прекрасно понимаю. слава богу, так о чем тогда спор? Долго выполняется - оптимизируйте сортировки в базе и full сканы. >киллд, да индекс именно на (a, b, c) кроме них в таблице >еще 2 поля. это вообще роли не играет, сколько там еще полей. >мне все больше начинает казаться, что при группировке >индекс не используется в принципе :( наконец-то. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:32 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
Действительно, если придется считывать все строки из таблицы, то Oracle будет использовать FullScan. Но, если у вас 1 поля a,b,c включены в индекс, 2 этот индекс начинается именно с них, например с поля a 3 в данной таблице существуют еще несколько доп.полей, которые "раздувают" одну строку, то, конечно, лучше заставить оптимизатор работать только с индексным файлом. Для этого можно либо включить хинт на использование этого индекса, либо поставить пустое по смыслу условие, например, where a>0, при котором будут выбираться все записи, но включается в работу индекс. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:35 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
не используется за исключением случая "покрывающего индекса". По сути индекс будет играть роль такого же источника данных как и таблица. Разница может быть за счет меньшего размера и сортировки. Какое нибудь из этих полей (a, b, c) определено как is not null ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:35 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
> оптимизируйте сортировки в базе именно этого я и хочу! но как? единственное, что есть для оптимизации сортировки - индекс! ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:37 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
>именно этого я и хочу! >но как? единственное, что есть для оптимизации >сортировки - индекс! 1. Где происходят сотртировки на диске или в памяти? 2. Если на диске, то нельзя ли их делать в памяти (sort_area_size)? 3. Если нельзя, то оптимизирован ли temporary tablespace (sort_multiblock_read_count и пр.)? 4. Что занимает больше времени FTS или сортировка? 5. Если FTS, то нельзя ли оптимизировать чтение с диска (db_file_multiblock_read_count)? вот в 2-х словах. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 15:44 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
>Но, если у вас >... поля a,b,c включены в индекс, Хм... по здравому размышлению должен признать, что был не прав, утверждая, что индекс при группировке никогда не будет использоваться. Вот сделал такой пример: Код: 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. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 17:06 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
Обрати внимание, что для первого случая нет операции сортировки. Кстати документация лукавит, говоря, что при INDEX FULL SCAN будут использоваться только одноблочные операции чтения. ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 17:20 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
супер!!!!!!!! спасибо!!!!! получилось!!!!!! только не понял почему.... видимо analyze помог. я так понимаю этот analyze собирает статистику по таблице, что б "правильнее" запросы опитмизировать? Если да, то видимо его нужно вызывать время-от времени? как часто? а может быть можно как-нибудь напрямую сказать оптимизатору, что б использовал индекс для группировки? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 17:29 |
|
оптимизация запроса с GROUP BY clause
|
|||
---|---|---|---|
#18+
>Кстати документация лукавит, говоря, что при INDEX >FULL SCAN будут использоваться только одноблочные >операции чтения. а как ты это определил? >Если да, то видимо его нужно вызывать время-от >времени? >как часто? >а может быть можно как-нибудь напрямую сказать >оптимизатору, что б использовал индекс для группировки? Я вызываю каждую ночь пакетом dbms_stat. Но вообще зависит от того как сильно изменяются данные в таблицах. Можно явно сказать хинтом. Код: 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. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105.
... |
|||
:
Нравится:
Не нравится:
|
|||
16.10.2002, 17:50 |
|
|
start [/forum/topic.php?fid=52&fpage=2837&tid=1992915]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
26ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
105ms |
get tp. blocked users: |
2ms |
others: | 13ms |
total: | 193ms |
0 / 0 |