MYSQL оптимизация индекса для таблицы, в которой хранятся отношения между двумя другими таблицами

Question

Мой вопрос касается структурирования базы данных для таблицы, которая связывает 2 другие таблицы для хранения отношений. Например,

, у меня есть 3 таблицы, users, locations и users_locations. * Таблицы 1006 *

users и locations имеют столбец id.

users_locations таблица содержит user_id и location_id из двух других таблиц.

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

например.

select user_id from users_locations where location_id = 5; 

или

select location_id from users_locations where user_id = 5;

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

Я не думаю, что смогу создать индекс для каждого столбца, так как будут дубликаты, например. несколько записей user_id для каждого местоположения и наоборот.

Будет ли добавление составного ключа, например PRIMARY_KEY (user_id, location_id), ускорять запросы, когда большинство запросов содержат только половину ключа?

Есть ли основания для просто установите поле AUTO INCREMENT PRIMARY_KEY в этой таблице, когда вы никогда не будете запрашивать по этому идентификатору?

Действительно ли мне нужно задать PRIMARY KEY?

Answer 1

Оптимальные индексы для таблицы сопоставления «многие ко многим»:

PRIMARY KEY (aid, bid),
INDEX(bid, aid)

Дополнительные обсуждения и дополнительные советы: http://mysql.rjweb.org/doc.php/index_cookbook_mysql#many_to_many_mapping_table

(Комментарии к специфике c пунктов в вопросе)

• FOREIGN KEYs неявно создают индексы, если явный индекс уже не был предоставлен.
• Составные индексы лучше подходят для таблиц "многие ко многим" .
• A FOREIGN KEY включает проверку целостности, поэтому она медленнее, чем просто наличие индекса. (А проверка целостности для таблиц такого типа имеет сомнительное значение.)
• Нет необходимости в AUTO_INCREMENT для таблицы многие: многие. Однако ...
• Важно иметь PRIMARY KEY на каждом столе. Пара столбцов хороша как "натуральная" PRIMARY KEY.
• В предложении WHERE хотелось бы использовать первый столбец (-ы) некоторого индекса; не беспокойтесь, что он не использует все столбцы.
• В EXPLAIN иногда вы видите «Использование индекса». Это означает, что был использован «индекс покрытия». Это означает, что все столбцы, используемые в SELECT, были найдены в этом одном индексе - без необходимости обращаться к данным, чтобы получить больше столбцов. Это повышение производительности. И требует двух индексов с двумя столбцами (один из них - PK, один - простой INDEX.)
• С InnoDB любой «вторичный» индекс (INDEX или UNIQUE) неявно включает столбцы ПК. Таким образом, учитывая PRIMARY KEY(a,b), INDEX(b), этот вторичный индекс фактически равен INDEX(b,a). Я предпочитаю указать два столбца, чтобы указать читателю, что я намеренно хотел, чтобы эти два столбца были в указанном порядке.
• Надеемся, что приведенная выше ссылка ответит на любые дополнительные вопросы.

Answer 2

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

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

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

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

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