Oracle не использует уникальный индекс для длинного ключа

У меня есть таблица с 250K строк в моей тестовой базе данных. (В производстве несколько сотен миллионов, мы можем наблюдать ту же проблему.) Таблица имеет строковый идентификатор nvarchar2 (50), а не ноль, с уникальным индексом (это не PK).

Идентификаторы состоят из первой части, имеющей 8 различных значений в моей тестовой базе данных (и около тысячи в производстве), затем знака @ и, наконец, числа длиной от 1 до 6 цифр. Например, может быть 50 тысяч строк, которые начинаются с 'ABCD_BGX1741F_2006_13_20110808.xml @', а за ним следуют 50 тысяч различных номеров.

Когда я запрашиваю одну строку на основе ее идентификатора, количество элементов оценивается как 1, стоимость очень низкая, она работает нормально. Когда я запрашиваю более одной строки с несколькими идентификаторами в выражении IN или выражении OR, оценки индекса совершенно неверны, поэтому используется полное сканирование таблицы. Если я намекаю на индекс с подсказкой, он очень быстрый, полное сканирование таблицы выполняется на порядок медленнее (и намного медленнее в производстве). Так что это проблема оптимизатора.

В качестве теста я продублировал таблицу (в той же схеме + табличное пространство) с точно таким же DDL и точно таким же содержимым. Я воссоздал уникальный индекс в первой таблице для хорошей меры и создал точно такой же индекс в таблице клонов. Я сделал DBMS_STATS.GATHER_SCHEMA_STATS('schemaname',estimate_percent=>100,cascade=>true);. Вы даже можете видеть, что имена индексов являются последовательными. Таким образом, теперь единственное различие между этими двумя таблицами состоит в том, что первая была загружена в произвольном порядке в течение длительного периода времени, когда на диске были разбросаны блоки (в табличном пространстве вместе с несколькими другими большими таблицами), вторая была загружена как одна пакетная. INSERT-SELECT. Кроме этого, я не могу представить никакой разницы. (Исходная таблица была уменьшена с момента последнего большого удаления, и после этого не было ни одного удаления.)

Вот планы запросов для таблицы больных и клонов (строки под черной кистью одинаковы по всей картинке, а также под серой кистью.):

(В этом примере есть 1867 строк, которые начинаются с идентификатора, выделенного черным цветом. 2-строчный запрос дает мощность 1867 * 2, 3-строчный запрос создает мощность 1867 * 3 и т. Д. По совпадению, Oracle, похоже, не заботится о конце идентификаторов.)

Что может вызвать такое поведение? Очевидно, было бы довольно дорого воссоздать таблицу в производстве.

USER_TABLES: http://i.stack.imgur.com/nDWze.jpg USER_INDEXES: http://i.stack.imgur.com/DG9um.jpg Я изменил только имя схемы и табличного пространства. Вы можете видеть, что имена таблиц и индексов такие же, как на скриншоте плана запросов.

(Это отвечает на другой вопрос о том, почему гистограммы отличаются.)

Гистограммы создаются по умолчанию на основе перекоса столбца и того, использовался ли столбец в соответствующем предикате. Копирование DDL и данных недостаточно, информация о рабочей нагрузке также важна.

Согласно Руководству по настройке производительности :

При удалении таблицы информация о рабочей нагрузке, используемая функцией автоматического сбора гистограмм, и сохраненная история статистики, используемая процедурами RESTORE _ * _ STATS, теряются. Без этих данных эти функции не работают должным образом.

Например, вот таблица с искаженными данными, но без гистограммы:

drop table test1;
create table test1(a date);
insert into test1 select date '2000-01-01'+level from dual connect by level <= 10;
insert into test1 select date '2000-01-01' from dual connect by level <= 1000;
begin
    dbms_stats.gather_table_stats(user, 'TEST1');
end;
/
select histogram from user_tab_columns where table_name = 'TEST1';

HISTOGRAM
---------
NONE

Если выполнить то же самое, но с запросом до сбора статистики, будет сгенерирована гистограмма.

drop table test1;
create table test1(a date);
insert into test1 select date '2000-01-01'+level from dual connect by level <= 10;
insert into test1 select date '2000-01-01' from dual connect by level <= 1000;
select count(*) from test1 where a = sysdate; --Only new line
begin
    dbms_stats.gather_table_stats(user, 'TEST1');
end;
/
select histogram from user_tab_columns where table_name = 'TEST1';

HISTOGRAM
---------
FREQUENCY

Я нашел решение! Это так красиво, и я действительно узнал много об Oracle.

Одним словом: гистограммы.

Я начал много читать о том, как работает ОО Oracle, и наткнулся на гистограммы. Я не до конца понял, поэтому взглянул на таблицу USER_HISTOGRAMS и вуаля. Там было несколько рядов для больного стола и практически ничего для клонированного стола. Для больной таблицы была одна строка для каждой из 8 различных частей-идентификаторов. И это ключ: они были обрезаны по 32 символа перед знаком @. Как я уже сказал, первая часть клавиш очень повторяющаяся, после знака @ они становятся разными.

Кажется, что гистограммы могут быть более мощными, чем простой факт, что уникальный индекс всегда имеет мощность 0 или 1 для данного значения. Когда я запрашивал 2+ строки, Oracle посмотрел на гистограмму, подумал, что для этой части, идентифицирующей начало, может быть десятки тысяч значений, и это сбило CBO с курса.

Я удалил гистограммы для этого столбца в старой таблице, и проблема исчезла!

Дополнительная информация: https://blogs.oracle.com/optimizer/entry/how_do_i_drop_an_existing_histogram_on_a_column_and_stop_the_auto_stats_gathering_job_from_creating

Я написал по электронной почте Джонатану Льюису об этом и получил очень полезный ответ:

Странность в вычислениях является следствием ограничений на символьные гистограммы, см., В частности:

http://jonathanlewis.wordpress.com/2010/10/13/frequency-histogram-5/ http://jonathanlewis.wordpress.com/2010/10/19/frequency-histograms-6/

Глядя на этот пример, запрос относится к списку IN, а не к одной строке, поэтому мое первоначальное предположение могло бы заключаться в том, что оптимизатор использовал общую стратегию для расчета селективности по нескольким строкам, а не имел специальный фрагмент кода для Список IN по первичному ключу. Полагаю, им было бы не сложно распознать этот случай, но разработчики, вероятно, не посчитали, что это стоит затраченных усилий.

Я настоятельно рекомендовал прочитать сообщения в блоге, на которые он ссылается, они подробно описывают ограничение гистограмм, в которые вы работаете, например:

Вывод : если у вас есть довольно длинные и похожие строки в столбце, который является хорошим кандидатом для частотной гистограммы (например, очень описательный столбец состояния), тогда у вас есть проблема, если очень редкое значение выглядит идентично очень популярному значение до первых 32 символов. Вы можете обнаружить, что единственным решением является изменение списка допустимых значений (хотя различные стратегии, включающие виртуальные столбцы или функциональные индексы, могут обойти проблему).