|
|
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубый индекс испорльзуется и пропала строчка Temporary Files Required For: Order By - значит сортировка идет по индексу? Куда он денется с подводной лодки? Покажи план того же запроса без /*+first_rows*/ SELECT FIRST 20 h.pos,... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 16:56 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Сугубый индекс испорльзуется и пропала строчка Temporary Files Required For: Order By - значит сортировка идет по индексу? Куда он денется с подводной лодки? Покажи план того же запроса без /*+first_rows*/ SELECT FIRST 20 h.pos,... Но если не используется Temporary Files, то не загружается tmpdb! А у нас боттлнек по каналу обращения к диску именно для tmpdb - постоянные сортировки идут. И тогда время отклика должно уменьшится... Это хорошая новость :) план не меняется Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:15 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
То есть в конец индексов мне бы хорошо еще добавить pos? тогда по нему будет сортировка идти. к примеру Код: plaintext 1. 2. 3. 4. 5. 6. сделать как Код: plaintext 1. 2. 3. 4. 5. 6. 7. я все правильно понимаю? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:18 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубый Но если не используется Temporary Files, то не загружается tmpdb! А у нас боттлнек по каналу обращения к диску именно для tmpdb - постоянные сортировки идут. И тогда время отклика должно уменьшится... Это хорошая новость :) Сортировки в файлах можно убрать перенеся их в ОЗУ (если она конечно есть). Используй PDQ. Или переходи на 9.4х4 и настраивай DS_NONPDQ_QUERY_MEM ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:22 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Кстати в 10-ке хинты можно не писать External Optimizer Directives The external optimizer directive is a new feature introduced in IBM® Informix® Dynamic Server, Version 10.0. This feature provides a more flexible way of specifying optimizer directives and optimizer hints. What it Does? In previous releases of Dynamic Server, optimizer directives existed within DML statements, but were not stored as separate database objects. External optimizer directives are useful when it is not feasible to rewrite a query for a short-term solution to a problem, for example, when a query starts to perform poorly. The database administrator can create external optimizer directives and apply them to subsequent queries, without changing existing application code. This feature is implemented as a new SQL statement, SAVE EXTERNAL DIRECTIVES, to create and register external optimizer directives in a new system catalog table called sysdirectives. Use the new IFX_EXTDIRECTIVES environment variable or the EXT_DIRECTIVES configuration parameter to enable this feature. The sysdirectives table stores external optimizer directives that can be applied to queries. Whether queries in client applications can use these optimizer directives depends on the setting of the IFX_EXTDIRECTIVES environment variable on the client system, and on the EXT_DIRECTIVES setting in the configuration file of the database server. Following is a structure of the sysdirectives table: Код: plaintext 1. 2. 3. 4. 5. 6. 7. How to use it? 1. Enable the external directive using a combination of the EXT_DIRECTIVES configuration parameter, and the IFX_EXTDIRECTIVES client-side environment variable. Queries within a given client application can use external directives if both the EXT_DIRECTIVES parameter in the configuration file and the IFX_EXTDIRECTIVES environment variable setting on the client system are both set to 1 or ON. The EXT_DIRECTIVE values that you can use are: Value Explanation 0 Off. The directive cannot be enabled even if IFX_EXTDIRECTIVES is on. 1 On. The directive can be enabled for a session if IFX_EXTDIRECTIVES is on. 2 (default) On. The directive can be used even if IFX_EXTDIRECTIVES is not set. IFX_EXTDIRECTIVES environment variable specifies whether the query optimizer allows external query optimization directives from the sysdirectives system catalog table to be applied to queries in existing applications. You can specify either ON and OFF or 1 and 0 to set the IFX_EXTDIRECTIVES environment variable. If IFX_EXTDIRECTIVES is not set, external directives are supported only if the ONCONFIG parameter EXT_DIRECTIVES is set to 2. The following table summarizes the effect of valid IFX_EXTDIRECTIVES and EXT_DIRECTIVES settings on support for external optimizer directives. Код: plaintext 1. 2. 3. 4. 5. 2. Use the SAVE EXTERNAL DIRECTIVES statement to create external optimizer directives for a specified query, and save the directives in the database. These directives are applied automatically to subsequent instances of the same query. Syntax Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. directive the optimizer directive valid for query query Text of a valid SELECT statement. NULL string is not valid Following is an example of SAVE EXTERNAL DIRECTIVES statement and corresponding entry in sysdirectives table: Код: plaintext 1. 2. 3. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Notes External directives are for occasional use only. The number of directives stored in the sysdirectives catalog should not exceed 50. A typical enterprise only needs 0 to 9 directives. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:24 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубыйя все правильно понимаю?Наверно неправильно. Мы вроде уже решили что индексировать numtrades не надо. Я думаю индекс по boardGroup тоже лишний. А по id надо отдельный индекс. Т.о. я вижу три индекса: CREATE INDEX (id) CREATE INDEX (trdate,pos) CREATE Uniq INDEX (pos) Если boardGroup это внешний ключ то можно на всякий добавить еще один индекс CREATE INDEX (boardGroup) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:28 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Сугубыйя все правильно понимаю?Наверно неправильно. Мы вроде уже решили что индексировать numtrades не надо. Я думаю индекс по boardGroup тоже лишний. А по id надо отдельный индекс. Т.о. я вижу три индекса: CREATE INDEX (id) CREATE INDEX (trdate,pos) CREATE Uniq INDEX (pos) Если boardGroup это внешний ключ то можно на всякий добавить еще один индекс CREATE INDEX (boardGroup) Эх, у меня запросы типовые. И в одном из типов есть Код: plaintext 1. 2. 3. так что индекс нужен. Каюсь, я взял первый попавшийся под руку индекс. Более правильно былоб обсуждать сл. индекс (оптимизатор берет именно его) Код: plaintext 1. 2. 3. 4. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Вопроос такой - стоит ли для этого индекса добавить в конец pos ? Для оптимизации сортировки. Насчет нескольких одиночных индексов: я считал что один составной индекс гораздо лучше нескольких одинарных. Я не прав? Завтра (уже) попробую создать эту кучку индексов и посмотреть, что там оптимизатор выберет... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2005, 17:44 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубый Эх, у меня запросы типовые. И в одном из типов есть Код: plaintext 1. 2. 3. Осмелюсь утверждать что индекс в который входит boardGroup, использоваться не будет. SELECT boardGroup FROM boardSelect должен вернуть такие значения чтобы их суммарная селективность h.boardGroup IN была лучше чем h.trdate, но какие именно значения вернуться подзапросом оптимизатор не знает, поэтому он возьмет среднестатистическую селективность и помножит на количество ожидаемых строк подзапроса, и получит нехорошую селективность. Еслиже случится такое несчастье что первым он решит выполнить подзапрос, то будет дисковая сортировка потому что подзапрос вернет несколько значений (по мнению оптимизатора), а в этом случае индекс (boardGroup, pos) принципиально нельзя использовать для order by pos. Еще раз предлагаю переделать IN на EXSIST. Сугубый INDEX (trdate, id); Вопроос такой - стоит ли для этого индекса добавить в конец pos ? Для оптимизации сортировки. (trdate, id, pos) Тоже самое -- будет дисковая сортировка. Сугубый Насчет нескольких одиночных индексов: я считал что один составной индекс гораздо лучше нескольких одинарных. Я не прав? Не прав. Индексы не должны быть ни длинными, ни короткими. Они должны быть такими какими нужны. Этими излишне длинными индексами вы жрете место на диске и замедляете операции обновления таблицы. СугубыйЗавтра (уже) попробую создать эту кучку индексов и посмотреть, что там оптимизатор выберет... :)Статистику после создания нового индекса собирайте LOW, high не НУЖЕН в этом случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 08:49 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
СугубыйДжойн мне немного сложнее формировать... Впрочем, где-то прочитал что подселекты оптимизатор все равно раскладывает в джойн. Раскладывает, но не всегда, и если разложит, то в плане это будет видно Query Plans for Subqueries http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.perf.doc/perf282.htm#sii-10query-32245 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 09:56 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
ТанРаскладывает, но не всегда, и если разложит, то в плане это будет видно Вообще интересный вопрос и сложный, оптимизатор FIRST 20 не видит. А в нашем случае может быть и не надо все h.boardGroup = (SELECT boardGroup FROM boardSelect WHERE boardGroupSet='repo|smal|' AND idSector='securies'), нам возможно не надо выполнять весь селект, а для первых "20" boardGroup проверить EXISTS (SELECT 1 FROM boardSelect WHERE boardGroupSet='repo|smal|' AND idSector='securies' and boardGroup=h.boardGroup) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 10:47 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Журавлев ДенисВообще интересный вопрос и сложный, оптимизатор FIRST 20 не видит. А в нашем случае может быть и не надо все h.boardGroup = (SELECT boardGroup FROM boardSelect WHERE boardGroupSet='repo|smal|' AND idSector='securies'), нам возможно не надо выполнять весь селект, а для первых "20" boardGroup проверить EXISTS (SELECT 1 FROM boardSelect WHERE boardGroupSet='repo|smal|' AND idSector='securies' and boardGroup=h.boardGroup) Нда, оптимизация - странная штука. Переход на EXISTS выйгрыша не дал: Код: 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. 116. 117. Общая стоимость запроса с IN меньше чем с EXISTS. Согласен, возможно индексы на ngcb_hist неоптимальны и из-за это такой разброс... Время выполнения оценить не удается - видимо данные попадают в кэш информикса и второй запрос всегда быстрее первого (я их пачкой пускаю в eSQLEditor, пробовал менять местами). boardselect - мельчайшая табличка, 22 записи, 4 колонки. Она полностью попадает в память. Другое дело secsLI - 14 тысяч записей (попутно кста на ней индекс оптимизировал) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 13:42 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Журавлев Денис Не прав. Индексы не должны быть ни длинными, ни короткими. Они должны быть такими какими нужны. Этими излишне длинными индексами вы жрете место на диске и замедляете операции обновления таблицы. По базе всегда идут только чтения (веб-сервер), обновление данных раз в сутки, вечером. Так что наличие множества индексов имхо оправдано. Места - пока хватает. Я заметил, что оптимизатор использует составные индексы охотнее, нежели чем отдельные по колонкам. И именно поэтому бьюсь над составными индексами, порядком колонок в них. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 13:47 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Тан СугубыйДжойн мне немного сложнее формировать... Впрочем, где-то прочитал что подселекты оптимизатор все равно раскладывает в джойн. Раскладывает, но не всегда, и если разложит, то в плане это будет видно Query Plans for Subqueries http://publib.boulder.ibm.com/infocenter/idshelp/v10/topic/com.ibm.perf.doc/perf282.htm#sii-10query-32245 Спасибо за уточнение. Теперь и сам вижу, что не раскладывает :) Но как показал эксперимент - не всегда разложение в джойн полезнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 13:49 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
СугубыйОбщая стоимость запроса с IN меньше чем с EXISTS. Согласен, возможно индексы на ngcb_hist неоптимальны и из-за это такой разброс... Время выполнения оценить не удается - видимо данные попадают в кэш информикса и второй запрос всегда быстрее первого (я их пачкой пускаю в eSQLEditor, пробовал менять местами). boardselect - мельчайшая табличка, 22 записи, 4 колонки. Она полностью попадает в память. Другое дело secsLI - 14 тысяч записей (попутно кста на ней индекс оптимизировал)а +first_rows ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 14:45 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Журавлев Дениса +first_rows план не изменился в обоих случаях. Даже больше, для SELECT /*+first_rows*/ h.pos, h.id, h.idBoard и для просто SELECT h.pos, h.id, h.idBoard (убрал FIRST 20) - тот же самый план выполнения (для IN и EXISTS). Там только иногда появляется "(Key-First)" но это я не создал всевозможные индексы еще. счас попробуем создать :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 15:09 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
СугубыйНо как показал эксперимент - не всегда разложение в джойн полезнее. "не всегда полезнее" - это иногда бесполезно? Или именно вредно?:) ЗЫ Если второе - хотелось бы посмотреть пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 16:53 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Valentyn Pidburtnyi СугубыйНо как показал эксперимент - не всегда разложение в джойн полезнее. "не всегда полезнее" - это иногда бесполезно? Или именно вредно?:) ЗЫ Если второе - хотелось бы посмотреть пример. я сужу по Estimated Cost в планах выполнения. Пример был уже дан в этом сообщении - я заменил конструкцию "IN" на "EXISTS" и Estimated Cost увеличилась. Сечас пишу скрипт замера времени выполнения - предварительно время выполнения запроса с EXISTS больше, хотя и не намного, на 1-2%. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 17:05 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
написал скрипт сравнения времен выполнения запросов. Прогоняет N раз рассматриваемую пару, вычисляет среднее время выполнения. Вот что получилось (первый запрос - с EXIST, второй - с IN): Код: plaintext 1. 2. 3. 4. то есть запрос с EXIST на 1.33 % медленнее чем с с IN :) (в сторону: мля, и на это я потратил полдня? ;) ничего, зато у меня теперь измерялка времен выполнения :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.12.2005, 18:48 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубыйя заменил конструкцию "IN" на "EXISTS" и Estimated Cost увеличилась. Сечас пишу скрипт замера времени выполнения - предварительно время выполнения запроса с EXISTS больше, хотя и не намного, на 1-2%. Да, теперь вижу: на своей базе тоже попробовал и тоже увидел, что иногда при exists оптимизатор выбирает план с бОльшей стоимостью. ЗЫ Не пробовал запускать запрос с собранным распределением (по колонкам, по которым есть фильтры и джойны) и без оного? Я у себя пока не могу потестить: тестовая база пустая, а рабочая.. Ну ты понял:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.12.2005, 17:13 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Valentyn Pidburtnyi Не пробовал запускать запрос с собранным распределением (по колонкам, по которым есть фильтры и джойны) и без оного? Это как? Я создал всевозможные (ну почти) индексы на всех колонках, участвующих в джойне, а после этого сделал UPDATE STATISTICS. Что есть "собранным распределением" ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2005, 12:15 |
|
||
|
Создание оптимальных индексов
|
|||
|---|---|---|---|
|
#18+
Сугубый Valentyn Pidburtnyi Не пробовал запускать запрос с собранным распределением (по колонкам, по которым есть фильтры и джойны) и без оного? Это как? Я создал всевозможные (ну почти) индексы на всех колонках, участвующих в джойне, а после этого сделал UPDATE STATISTICS. Что есть "собранным распределением" ? update statistics high или medium по фильтруемым полям таблиц. Можно distributions only, чтобы не делалось лишней работы, которая и так у тебя уже сделана после update statistics low. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2005, 15:38 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=33409236&tid=1608822]: |
0ms |
get settings: |
5ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
31ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 186ms |
| total: | 284ms |

| 0 / 0 |
