MySQL: уникальная оптимизация производительности нескольких столбцов

Question

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

У меня есть таблица, которая просто: tableA_id tableB_id

Мой первичный ключ является уникальным ограничением для обеих таблиц, и у меня есть индекс для обоих столбцов. Оба также являются первичными ключами к своим уважаемым таблицам.

Если для tableA, вероятно, будет указано, например, 10 000 000 строк, а для таблицы B - 2 000 000, более вероятно, что TableB будет находиться в этом ограничении гораздо реже. Как это ни печально, является ли это более оптимизированным, когда я устанавливаю свое уникальное ограничение, чтобы поместить TableB в качестве первого столбца, так как искать меньше, TableA (если так, почему), или это не имеет значения, так как он не выполняет поиск сначала другой, скорее, идет один за другим, глядя на обоих.

Заранее спасибо

Answer 1

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

Форма цитаты Документы MySQL :

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

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

Answer 2

Из вашего описания я предполагаю, что у вас есть следующее:

UNIQUE (tableA_id, tableB_id)
INDEX (tableA_id)
INDEX (tableB_id

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

Я не думаю, что оптимизатор MySQL достаточно умен, чтобы использовать индекс PK для оператора, который содержит WHERE tableB_id = 42.

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

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