Ограничения для следования для Индексации в MySQL

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

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

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

Одна вещь, которую я настоятельно рекомендую при определении влияния индекса, - это посмотреть на план запроса, чтобы определить, какой индекс используется. Если вы пытаетесь ускорить выполнение данного запроса, это покажет вам, помог ли индекс.

Две причины для индексации: производительность запросов / DML и соблюдение ограничений.

Для первого:

Индексы должны поддерживаться ... новые записи должны быть вставлены, изменения перемещены, удалены удалены. Для каждого DML в таблице также есть по одному на каждый индекс. Таблица с 8 индексами означает, что на каждый DML выполняется в 8 раз больше работы (примерно).

В индексных данных "есть куда пойти". 2 должно находиться между 1 и 3. Если для этого нового значения нет места, происходит разбиение блоков (читай: накладные расходы).

Не следует индексировать каждый столбец, который может находиться в предложении where. Столбцы с низкой мощностью или сканирование диапазона для сильно разрозненных данных обычно не используют индекс. В большинстве случаев СУБД может использовать только один индекс для каждой таблицы. (В некоторых случаях индексы могут быть соединены друг с другом). Поэтому некоторые индексы должны быть в нескольких столбцах.

ОТВЕТ НА КОММЕНТАРИЙ:

Сначала, если у вас есть предложение where со столбцом A и столбцом B. И у вас есть два индекса: один на colA, а другой на colB ... вполне вероятно, что оптимизатор решит использовать один или другой, в зависимости от избирательности предиката и самого индекса. Другой предикат будет просто фильтром результатов сканирования индекса и полученного доступа к таблице. Вы будете обрабатывать гораздо больше блоков таблицы, чем нужно ... и если ни один из индексов не будет достаточно избирательным, вы все равно получите FTS.

Но если вам часто нужны colA и colB в предложениях where вместе, вы можете построить индекс для обоих столбцов одновременно. Теперь оба предиката будут использоваться для ограничения доступа к результирующему блоку таблицы только теми, которые содержат необходимую строку.

Теперь важен ведущий столбец.