Oracle не використовує унікальний індекс для довгого ключа

У мене в тестовій базі даних є таблиця з 250K рядками. (У виробництві є кілька сотень мільйонів, ми можемо спостерігати ту саму проблему.) У таблиці є рядковий ідентифікатор nvarchar2 (50), не нульовий, з унікальним індексом на ньому (це не ПК).

Ідентифікатори складаються з першої частини, яка містить 8 різних значень у моїй тестовій базі даних (і близько тисячі у виробництві), потім знак @ і, нарешті, число, довжиною від 1 до 6 цифр. Наприклад, може бути 50 тисяч рядків, які починаються з "ABCD_BGX1741F_2006_13_20110808.xml @", а за ним слідує 50 тисяч різних цифр.

Коли я запитую один рядок на основі його ідентифікатора, кардинальність оцінюється як 1, вартість дуже низька, він працює чудово. Коли я запитую більше ніж один рядок з декількома ідентифікаторами у виразі IN чи ІЛИ, то оцінки індексу є абсолютно неправильними, тому використовується повне сканування таблиці. Якщо я змушую індекс натяком, це дуже швидко, сканування повної таблиці фактично виконується на порядок повільніше (і набагато повільніше у виробництві). Тож це проблема оптимізатора.

Як тест, я дублював таблицю (в тій же схемі + простір таблиць) з точно таким же DDL і точно таким же вмістом. Я відтворив унікальний індекс на першій таблиці для гарної міри та створив такий самий індекс на таблиці клонування. Я зробив а DBMS_STATS.GATHER_SCHEMA_STATS('schemaname',estimate_percent=>100,cascade=>true);. Ви навіть можете побачити, що імена індексів є послідовними. Тож тепер єдина відмінність між двома таблицями полягає в тому, що перша була завантажена у випадковому порядку протягом тривалого періоду, з блоками, розкиданими на диску (у табличному просторі разом з кількома іншими великими таблицями), друга завантажувалася як одна партія ВСТАВИТЬ-ВИБІР. Крім цього, я не можу уявити ніякої різниці. (Початкова таблиця була зменшена з моменту останнього великого видалення; після цього не було жодного видалення.)

Ось плани запитів для хворих та клоніруючої таблиці (Рядки під чорною щіткою однакові по всьому малюнку, а також під сірою кистю.):

(У цьому прикладі є 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.

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

Я почав багато читати про те, як працює CBO Oracle, і я натрапив на гістограми. Я не повністю зрозумів, тому я подивився на таблицю USER_HISTOGRAMS та voilá. Для хворого столу було кілька рядів, а для клонованого столу практично нічого. Для таблиці хворих був один ряд для кожної з 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 символів. Ви можете виявити, що єдиним рішенням є зміна списку юридичних значень (хоча різні стратегії, що включають віртуальні стовпці або на основі функцій, можуть усунути проблему).