Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Активность индексов и "мертвые" индексы
|
|||
|---|---|---|---|
|
#18+
В CDI недавно был интересный топик " unused indexes (Informix 7.31) " http://groups.google.com/group/comp.databases.informix/browse_thread/thread/31fc8ac6392f5290/b2303ce2538c1e5b?lnk=gst&q=unused+indexes+(Informix+7.31)#b2303ce2538c1e5b Обсуждение еще продолжается, но это подвигло меня на создание парочки запросов по мотивам этой темы (табличку sysptnkey я до этого не использовал). Как совершенно справедливо заметил Habichtsberg, Reinhard (CDI) - Which of the values is significant for the usage of the index? It can't be all the values because insert, delete or update of rows of the related table will change some of the values. That has nothing to do with the usage of the index by queries. My thought is that isreads, pagereads and bufreads may be significant but it's only a guess. И вряд ли заданный в топике вопрос (как определить и затем удалить неиспользуемые индексы) решается нормально в текущих версиях (не знаю, как дела в 11), тем не менее, мне показалось интересным определить активность индексов (по сумме всех операций вв/выв) и т.н. "мертвые" индексы, по которым операций вв/выв совсем нет в течении длительного времени. Это интересно даже с точки зрения проверки работы планов оптимизатора, использования/неиспользования конкретных индексов и т.п. Как обычно, запросы оптимизированы под вывод через dbaccess (строки не более 80) Код: 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. Код: 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. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2008, 21:16 |
|
||
|
Активность индексов и "мертвые" индексы
|
|||
|---|---|---|---|
|
#18+
Еще на эту же тему из Informix FAQ http://www.informixfaq.com/wiki/doku.php/wiki:sysmaster#how_to_list_the_users What are the poor indexes The following sql can identify sql using poor indexes Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.06.2008, 22:31 |
|
||
|
Активность индексов и "мертвые" индексы
|
|||
|---|---|---|---|
|
#18+
vasilis по которым операций вв/выв совсем нет в течении длительного времени. Это интересно даже с точки зрения проверки работы планов оптимизатора, использования/неиспользования конкретных индексов и т.п. Как обычно, запросы оптимизированы под вывод через dbaccess (строки не более 80) Для меня гораздо больший практический интерес представляет ситуация когда индекс не используется по доступу на чтение(select) или изменение( update). При вставке и удалении записей в таблицу индексы тоже читаются и изменяются, если же для select, update они не используются - это пустая работа . Поэтому от таких индексов нужно избавляться в первую очередь. Такие индексы вредят производительности гораздо больше, чем просто мертвые индексы. С уважением, onstat. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2008, 17:22 |
|
||
|
Активность индексов и "мертвые" индексы
|
|||
|---|---|---|---|
|
#18+
Признаюсь чесно времени подробно вникать в тему у меня небыло. Если что не так сказал или кого повторил, заранее прошу прощения. ИМХО Для вычисления действительно плохих индексов в VNext было бы полезно завести отдельные счетчики bufreads & bufwrites в sysptprof или какой либо другой таблице, по критериям insert-delete & select-update тогда вычисление вредных индексов сильно упростилось бы. При должном подходе СУБД могла-бы сама бросаться собщениями типа : Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.06.2008, 17:44 |
|
||
|
|

start [/forum/topic.php?fid=44&fpage=36&tid=1608078]: |
0ms |
get settings: |
9ms |
get forum list: |
9ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
24ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 267ms |
| total: | 352ms |

| 0 / 0 |
