Индексирование каждого столбца в таблице - PullRequest
12 голосов
/ 09 июля 2010

У меня есть пара вопросов относительно индексации MySQL:

1) Есть ли увеличение скорости при индексации таблицы, хранящейся в памяти?

2) При поиске в моей таблице, в которой я сопоставляю поле столбца, будет ли индексирование каждого столбца противоречить цели индекса?

Большое спасибо.

Ответы [ 4 ]

20 голосов
/ 09 июля 2010

Индексирование любой таблицы, основанной на памяти или файловой системе, ускорит запросы, которые выбирают или сортируют результаты на основе этого столбца.Это связано с тем, что индекс работает как древовидная структура , а расстояние поиска зависит от глубины дерева, которая увеличивается намного медленнее, чем количество строк в столбце (логарифмическое).

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

Другие вопросы SO, которые необходимо прочитать по этому вопросу:

Рекомендации по индексированию
Что такое индекс
Сколько индексов достаточно

2 голосов
/ 09 июля 2010

1) Да, конечно.
2) Нет, это не противоречит цели индекса.Просто помните, что mysql не может использовать более 1 индекса на таблицу и что добавление большего количества индексов замедляет операции вставки / обновления / удаления.Поэтому избегайте создания неиспользуемых индексов, вместо этого создайте многоколоночные индексы, которые лучше всего соответствуют вашим запросам.

0 голосов
/ 06 февраля 2019

Re Q1 ... Оптимизатор запросов иногда предпочитает сканировать таблицу, даже если существует «совершенно хороший» индекс.Этот компромисс основан на сложном алгоритме, но, как правило:

Если необходимо использовать более ~ 20% индекса, считается более эффективным игнорировать индекс и просто сканироватьtable.

Причина в следующем: использование индекса означает сканирование индекса BTree (который очень похож на таблицу), а затем перепрыгивание на данные BTree для поиска записи.Этого назад и вперед избегают, если он просто сканирует данные.Недостатком является то, что ему нужно игнорировать до 80% строк.

Следствие: не беспокойтесь о индексировании «флагов» (0/1, T / F, M / F, Yes / No) илистолбцы с низкой кардинальностью (да / нет / возможно, M / F / и т. д., день недели, ...).

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

WHERE deleted=0 AND created_at > NOW() - INTERVAL 1 DAY
INDEX(deleted, created_at)
0 голосов
/ 10 декабря 2011

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

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

Использование индексовзанимают место на диске для хранения и занимают время для создания и обслуживания.Неиспользованные не дают никакой пользы.Если для запроса имеется много индексов-кандидатов, запрос может быть замедлен, если сервер выберет «неправильный» для запроса.

Используйте эти факторы, чтобы решить, нужен ли вам индекс.

Обычно можно создавать индексы, которые НИКОГДА не будут использоваться - например, и индекс для (не нулевого) поля только с двумя возможными значениями почти наверняка будет бесполезным.

Вынеобходимо объяснить запросы вашего собственного приложения, чтобы убедиться, что часто выполняемые используют разумные индексы, если это возможно, и создать не больше индексов, чем требуется для этого.

Вы можете получить больше, перейдя по этим ссылкам: Дляmysql: http://www.mysqlfaqs.net/mysql-faqs/Indexes/What-are-advantages-and-disadvantages-of-indexes-in-MySQL

Для DB2: http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005052.htm

...