Индексирование каждого столбца в таблице

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

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

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

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


person Linus Norton    schedule 09.07.2010    source источник


Ответы (4)


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

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

Другие вопросы SO для чтения, связанные с этим вопросом:

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

person Fuu    schedule 09.07.2010
comment
Полезное правило: разветвление для MySQL BTrees равно 100. Следовательно, для таблицы или индекса с _billion_rows потребуется глубина дерева около 5. - person Rick James; 06.02.2019

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

person Naktibalda    schedule 09.07.2010
comment
Я считаю, что MySQL, начиная с версии 5.0, может использовать более одного индекса для каждой таблицы. Это не будет так эффективно, как единый индекс для тех же столбцов, но часто лучше, чем полное сканирование таблицы. - person Ken; 11.07.2010

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

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

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

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

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

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

Вы можете получить больше, следуя этим ссылкам: Для 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

person Somnath Muluk    schedule 10.12.2011

По вопросу Q1 ... Оптимизатор запросов иногда выбирает сканирование таблицы, даже если имеется "совершенно хороший" индекс. Этот компромисс основан на сложном алгоритме, но, как правило:

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

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

Следствие: не беспокойтесь об индексировании "флагов" (0/1, T / F, M / F, Да / Нет) или столбцов с низкой мощностью (да / нет / возможно, M / F / и т. Д., День недели, ...).

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

WHERE deleted=0 AND created_at > NOW() - INTERVAL 1 DAY
INDEX(deleted, created_at)
person Rick James    schedule 06.02.2019