Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
Есть 2 таблицы: Код: 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. Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 15:09 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
Для таблицы ATTRIBUTES логично использовать сканирование таблицы. Не надо делать чтение индекса, т.к. в любом случае надо читать данные таблицы. Для талицы VARIABLES получаем множество ключей из предыдущей таблицы. Опять же, чтение индекса не выгодно, т.к. надо читать данные из таблицы. Когда, стоимость чтение индекса и поднятия страниц данных станет дешевле стоимости чтения всей таблицы, тогда БД будет использовать индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 15:29 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
но операция сканирования слишком дорогая, нельзя ли увеличить производительность такого запроса? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 16:24 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
может размер таблиц небольшой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 17:11 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
Размер таблицы может быть очень большим. Однако, СУБД может посчитать, что полное сканирование таблицы дешевле. С такой штукой я сталкивался и при работе с Oracle, где количество записей в таблице было около 10^7. На Oracle спасло ситуацию использование хинта - нужно быстрее получить первую запись. В этом случае СУБД оценивало, что получить быстрый ответ легче, если используется индекс. Суммарное время общей выборки получалось немного медленнее, нежели полное сканирование. Исходя из вашего запроса, напрашивается использование индекса для ATTRIBUTES по полю ID_PROCESS. Можно попробовать обмануть БД, написав предварительную выборку из объединения множеств индексов. Код: plaintext 1. 2. 3. 4. 5. 6. 7. Если оптимизатор шибко умный, он поймет, что его хотят надуть и возьмет полное сканирование. В противном случе он для первой выборки воспользуется индексами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.11.2007, 21:00 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
db2advis не пробовал? Мы обычно его используем, потом смотрим какие индексы он хочет и т.п. Таким образом оптимизируем запросы, получается неплохо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.11.2007, 09:41 |
|
||
|
Использование индекса
|
|||
|---|---|---|---|
|
#18+
Недавно читал статью: http://www.dbazine.com/db2/db2-mfarticles/mullins-db2indexing Там есть такая фраза: Sometimes, however, it can be advantageous to include additional columns in an index to increase the chances of index-only access. (Index-only access is discussed further in Chapter 21 “The Optimizer.”) For example, suppose that there is an index on the DEPTNO column of the DSN8810.DEPT table... И ещё такой совет: keep creating indexes to enhance the performance of your queries until the performance of data modification becomes unacceptable. Then delete the last index you created. Может быть Вам попробовать создать некластерный индекс по полям A.VALUE_VAR, V.ID_VAR, A.ID_PROCESS - я предполагаю что у A.VALUE_VAR минимальная селективность (cardinality). Тогда оптимизатор, по-идее, должен "увидеть" возможность считать данные из индекса и соответственно выберет индекс. Было бы интересно узнать результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.11.2007, 21:22 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=34958603&tid=1604175]: |
0ms |
get settings: |
7ms |
get forum list: |
11ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
35ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 221ms |
| total: | 320ms |

| 0 / 0 |
