Собирать статистику по индексу или создать капюшон?

Question

Отбрасывание и восстановление индекса имеют тот же эффект, что и при использовании dbms.gather_index_stats? (Имеет ли тот же эффект, что и восстановление/обновление индекса)

Или эти две совершенно разные вещи, которые нельзя сравнивать друг с другом?

Answer 1

Разница заключается в том, что сбор статистических данных обновляет метаданные о текущем индексе, тогда как сброс и повторное создание индекса - это эр, удаление и повторное создание индекса.

Возможно, легко понять разницу с обработанным примером. Итак, создадим таблицу и индекс:

SQL> create table t23 
    2 as select object_id as id, object_name as name from user_objects 
    3/

Table created. 

SQL> create index i23 on t23(id) 
    2/

Index created. 

SQL> select o.object_id, i.last_analyzed, i.distinct_keys 
    2 from user_objects o 
    3  join user_indexes i 
    4   on (i.index_name = o.object_name) 
    5 where o.object_type = 'INDEX' 
    6 and i.index_name = 'I23' 
    7/

OBJECT_ID CREATED    LAST_ANALYZED  DISTINCT_KEYS 
---------- -------------------- -------------------- ------------- 
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:15:39   167 

1 row selected. 

SQL> 

С 11 г Oracle автоматически собирает статистику при создании индекса. Таким образом, создание индекса и последний анализ показывают одно и то же время. В предыдущих версиях нам приходилось явно собирать статистику после создания индекса. Find out more.

Далее мы добавим некоторые данные и обновить статистику:

SQL> insert into t23 values (9999, 'TEST1') 
    2/

1 row created. 

SQL> insert into t23 values (-8888, 'TEST 2') 
    2/

1 row created. 

SQL> exec dbms_stats.gather_index_stats(user, 'I23') 

PL/SQL procedure successfully completed. 

SQL> select o.object_id, i.last_analyzed, i.distinct_keys 
    2 from user_objects o 
    3  join user_indexes i 
    4   on (i.index_name = o.object_name) 
    5 where o.object_type = 'INDEX' 
    6 and i.index_name = 'I23' 
    7/

OBJECT_ID CREATED    LAST_ANALYZED  DISTINCT_KEYS 
---------- -------------------- -------------------- ------------- 
    116353 23-NOV-2013 00:15:39 23-NOV-2013 00:26:28   169 

1 row selected. 

SQL> 

Теперь метаданные, относящиеся к статистике изменились, но индекс и тот же объект базы данных. Принимая во внимание, если мы падаем и заново создать индекс, мы получаем новый объект базы данных:

SQL> drop index i23 
    2/

Index dropped. 

SQL> create index i23 on t23(id) 
    2/

Index created. 

SQL> select o.object_id, i.last_analyzed, i.distinct_keys 
    2 from user_objects o 
    3  join user_indexes i 
    4   on (i.index_name = o.object_name) 
    5 where o.object_type = 'INDEX' 
    6 and i.index_name = 'I23' 
    7/

OBJECT_ID CREATED    LAST_ANALYZED  DISTINCT_KEYS 
---------- -------------------- -------------------- ------------- 
    116354 23-NOV-2013 00:27:50 23-NOV-2013 00:27:50   169 

1 row selected. 

SQL> 

---

В нормальных условиях мы вряд ли когда-нибудь понадобится удалить и повторно создать индекс. Это метод, который когда-то подходит при загрузке очень больших объемов данных и в очень редких случаях повреждения индекса. Интервесты все еще бросают сайты, которые рекомендуют регулярно перестраивать индексы по причинам производительности (предположительно это «перебалансирует» перекошенные индексы), но эти сайты не дают ориентиров, чтобы доказать долгосрочные выгоды, и, конечно же, никогда не включают время и Процессы ЦП теряются в результате перестройки.

---

«Я в настоящее время пытается справиться с оптимизацией загрузки и обновления огромное количество данных, и готов нанести удар, который был лучше сделать»

Перестроение индекса требует больше работы, чем освежающий статистика. Очевидно, верно, потому что перестройка включает сбор статистики в качестве подзадачи. Вопрос в том, эффективнее ли проводить объемный DML против таблицы с ее индексами на месте по сравнению с уменьшением индексов и последующим повторным созданием. Быстрее загружать данные в таблицу без индексов и впоследствии создавать их повторно.

Здесь нет жесткого правила: это зависит от того, сколько индексов у вас есть, доля строк, затронутых всем размером таблицы, нужны ли вам индексы для обеспечения ограничений реляционной целостности и скоро. Существует также большая разница между операциями: вы можете отказаться от индексов для массовых вставок, но сохранить их для обновлений, в зависимости от того, какие индексы вам нужны для предложения WHERE и влияет ли обновление на индексированные столбцы.

Короче говоря, вам необходимо провести оценку вашего собственного конкретного сценария. Это часто является ответом на вопросы о производительности.