Oracle 11g автоматически индексирует поля, часто используемые для полного сканирования таблиц?

Question

У меня есть приложение, использующее базу данных Oracle 11g. У меня есть довольно большая таблица (~ 50 тыс. Строк), которую я запрашиваю таким образом:

SELECT omg, ponies FROM table WHERE x = 4

Поле x не было проиндексировано, я обнаружил. Этот запрос выполняется lot , но дело в том, что производительность была не слишком плохой. Добавление индекса на x сделало запросы примерно в два раза быстрее, что намного меньше, чем я ожидал. На MySQL, скажем, это сделало бы запрос в десять раз быстрее, по крайней мере. ( Редактировать: Я проверил это на MySQL, и там увидели огромную разницу.)

Я подозреваю, что Oracle добавляет какой-то автоматический индекс, когда обнаруживает, что я часто запрашиваю неиндексированное поле. Я прав? Я не могу найти ничего, даже подразумевая это в документах.

Answer 1

Как уже указывалось, Oracle11g НЕ динамически строит индексы на основе предыдущего опыта. Конечно, возможно, и действительно часто случается, что добавление индекса в правильных условиях приведет к улучшению на порядок, который вы заметите.

Но, как уже отмечалось, строки в 50 КБ (казалось бы, короткие?) Для Oracle ничего не значат. На самом деле база данных Oracle обладает большим интеллектом, который позволяет ей сканировать данные без индексов наиболее эффективно. Каждый новый выпуск СУБД Oracle совершенствуется при перемещении больших объемов данных. Я хотел бы предложить вам, что причина, по которой Oracle был так близок к своему «лучшему» времени даже без индекса по сравнению с MySQL, заключается в том, что Oracle - это просто более интеллектуальная база данных под прикрытием.

Тем не менее, СУБД Oracle имеет много функций, которые касаются предметной области, которую вы открыли. Например:

10g представила функцию AUTOMATIC SQL TUNING, которая предоставляется через интерфейс, известный как SQL TUNING ADVISOR. Эта функция предназначена для глубокого анализа запросов и включает в себя возможность выполнять ЧЕГО-IF анализ альтернативных планов запросов. Это включает в себя моделирование индексов, которые на самом деле не существуют. Однако это не объясняет каких-либо различий в производительности, которые вы видели, поскольку эту функцию необходимо включить, и она фактически не строит никаких индексов, она лишь дает рекомендации для администратора баз данных по созданию индексов, среди прочего.

11g включает в себя АВТОМАТИЧЕСКИЙ СБОР СТАТИСТИКИ, который при включении будет автоматически собирать статистику по объектам базы данных, если сочтет это необходимым, основываясь на активности этих объектов.

Таким образом, СУБД Oracle делает то, что вы предложили, динамически самостоятельно изменяя свою среду, основываясь на опыте работы с вашей нагрузкой, чтобы повысить производительность. Создание индексов на лету - это еще не то, чем занимается. Кроме того, на это намекнул Oracle в частном порядке несколько раз, поэтому я полагаю, что он готовится к будущему выпуску.

Answer 2

~ 50К строк, в значительной степени зависящие от размера каждой строки, могут храниться менее чем в 1000 блоках, которые могут быть быстро считаны в буферный кэш путем полного сканирования таблицы (FTS) в менее чем 50 многоблочных чтениях.

Добавление соответствующего индекса (-ов) позволит плавно масштабировать запросы к таблице по мере увеличения объема данных и / или частоты доступа.

Answer 3

Что касается проблемы MySQL, то какой механизм хранения вы используете, может иметь значение.

«MyISAM полагается на операционную систему для кэширования чтения и записи в строки данных, в то время как InnoDB делает это в самом движке»

Oracle будет кэшировать строки таблицы / данных, поэтому ему не нужно будет попадать на диск. в зависимости от операционной системы и аппаратного обеспечения MySQL может быть каждый раз физически считывать данные с диска каждый раз.

Answer 4

"Добавление индекса на x сделало запросы примерно в два раза быстрее, что намного меньше, чем я ожидал. На, скажем, MySQL, это сделало бы запрос в десять раз быстрее, как минимум. "

Сколько существует различных значений X? Они сгруппированы в одной части таблицы или равномерно распределены по ней?

Индексы не являются каким-то устройством вуду: они должны подчиняться законам физики.

1010 * редактировать *

"Дубликаты могут появляться, но по мере есть, нет ни одного. "

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

Answer 5

Oracle 11g автоматически индексирует поля, часто используемые для полного сканирования таблиц?

номер

Answer 6

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

50 тыс. Строк - не такая большая таблица, поэтому я не удивлюсь, если производительность будет достойной даже без индекса. Таким образом, добавление индекса в уравнение не может значительно улучшить скорость выполнения запроса.