|
|
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
Доброго всем. Суть задачи: есть таблица, в которой хранятся логи входа в систему. В ней есть строки вида:"Регистрация пользователя %USER% в системе". Таблица в одной из прод.базе занимает 5Гб. (это минимум, на других больше) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. "Нужных" индексов на таблице нет. Помимо регистрации пользователя - есть и другие события в таблице, но их меньше примерно в 2 раза (65% - Регистрации пользователя / 35% прочее). При этом есть еще служебные пользователи, их тоже большинство. Решил создать FBI (откинем прочие события и служебных пользователей) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Теперь если мы выбираем по FBI должно выбираться по индексу, НО: если я выбираю само значение функции. то все в порядке: Код: plsql 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. а если я в выборку добавлю поле из таблицы, то он уже не хочет строить по FBI : Код: plsql 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. Почему так? Я понимаю если бы я менял where условие, но в выборке?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 19:15 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
Я так и не понял, какой же процент строк попал в индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 19:27 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
favt, Привет, Костя :) а зачем такой индекс без даты-то? Добавь в индекс первым полем дату и в запрос ограничение по дате ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 20:20 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
xtender, Спалился я, похоже. Так в том то и дело, что ограничивать по дате мне и не надо.Точнее мне надо будет искать: когда пользователь последний раз входил под РМ. (group by description). Да и добавление в индекс поля даты сводит на нет его селективность и размер. Я хотел чтобы он хранил только соединения обычных пользователей. Elic. Пока мне сложно судить, постараюсь завтра дождаться выводов. Любой fullscan таблицы выполняется более часа. По моим "предположительным" подсчетам в индекс должно попасть не более 10% строк от всей таблицы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.10.2016, 23:59 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
Поведение оптимизатора понятно. Пока нет необходимости лезть в таблицу - он согласен фуллсканить индекс, поскольку его сегмент меньше по размерам. Но если требуются отсутствующие в индексе поля - то, увы и ах, лазить за ними в таблицу по rowid при том, что проиндексировано до 65% строк - изврат. Задача поиска "последний раз заходил" в данном случае может быть решена скорее не функциональным, а доменным индексом. Заодно и на размере можно конкретно выиграть. Ключевое слово для гугла - ODCIIndex ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 02:13 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
favt, Fbi добавляет столбец в таблицу, оно тебе надо? Не проще ли триггер повесить с when и мерджить в новую таблицу нужное? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 03:13 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
В новой таблице только поля имени пользователя, раб.места и дата, ну и уникальный индекс на пользователя и раб.место ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 03:15 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
xtenderFbi добавляет столбец в таблицуОн добавляет псевдо -столбец, реально данные (выражения) хранятся только в индексе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 03:34 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
У меня больше даже вопрос: Почему? В доках читаю (видать невнимательно?!) что select * from table where FBI(col)=aval должен идти по индексу, Так почему при добавлении поля в Select (Когда даже ВСЕ столбцы должны) план не хочет подхватывать индекс? Индекс же содержит rowid нужных записей? Он по ним должен вытаскивать строки таблицы? И да, если поставить вместо Код: sql 1. Код: sql 1. Тогда в плане уже идет поиск по Index Range Scan Саян, Тут триггером даже нагружать и не хочу, мне надо за все время отчет. Так, в целом я могу ограничиться EVENTTIME, на нем есть индекс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 10:00 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
favtУ меня больше даже вопрос: Почему? В доках читаю (видать невнимательно?!) что select * from table where FBI(col)=aval должен идти по индексу... Никто Никому Ничего Не должен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 10:03 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
favtУ меня больше даже вопрос: Почему? В доках читаю (видать невнимательно?!) что select * from table where FBI(col)=aval должен идти по индексу, Так почему при добавлении поля в Select (Когда даже ВСЕ столбцы должны) план не хочет подхватывать индекс? Индекс же содержит rowid нужных записей? Он по ним должен вытаскивать строки таблицы? И да, если поставить вместо Код: sql 1. Код: sql 1. Тогда в плане уже идет поиск по Index Range Scan Саян, Тут триггером даже нагружать и не хочу, мне надо за все время отчет. Так, в целом я могу ограничиться EVENTTIME, на нем есть индекс.Он не должен как минимум потому что это может быть очень неэффективно медленными одноблочными чтениями тащить данные из индекса, а потом медленными одноблочными из таблицы по сравнению с быстрыми многоблочными full scan / fast full scan. В твоем изначальном примере INDEX RANGE SCAN существует только из-за предиката по ROWNUM. Поэтому надо определиться, либо оптимизировать под ROWNUM, и тогда индекс вполне оправдан, либо не пользовать ROWNUM в тестах вообще. Если FULLSCAN таблицы на 5GB выполняется больше часа, то желательно понять с чем связана скорость в 1 MB/s. Мы же понимаем, что современные скорости в 100-1000 раз быстрее? Также надо собирать статистику на hidden column, по-моему она по дефолту не собирается, хотя могу ошибаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 11:50 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
wurduТакже надо собирать статистику на hidden column, по-моему она по дефолту не собирается, хотя могу ошибаться. Собирается. Тут ТС все верно сделал, создал FBI - обязательно собери статистику таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 12:12 |
|
||
|
FBI, непонятка с планом.
|
|||
|---|---|---|---|
|
#18+
AlexFF__|wurduТакже надо собирать статистику на hidden column, по-моему она по дефолту не собирается, хотя могу ошибаться. Собирается. Тут ТС все верно сделал, создал FBI - обязательно собери статистику таблицы. Ага) и не забыть про прикол Код: plsql 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.10.2016, 12:27 |
|
||
|
|

start [/forum/topic.php?fid=52&msg=39325809&tid=1887241]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
69ms |
get tp. blocked users: |
1ms |
| others: | 248ms |
| total: | 526ms |

| 0 / 0 |
