Задать вопрос

Mysql — как оптимизировать связь Many To Many?

Добрый день. Есть ряд вопросов по оптимизации SELECT запросов, надеюсь на вашу помощь)

Имеется две таблицы: product (товары) и product_relation (сопутствующие товары). Связь - многие ко многим.
Какая схема будет более оптимальной?
CREATE TABLE `product_relation`(
  `id` INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
  `product_id` Int(11) NOT NULL,
  `relation_id` Int(11) NOT NULL,
  `is_del` ENUM("n", "y") NOT NULL,
 PRIMARY KEY (`id`)
) ENGINE = InnoDB;

или
CREATE TABLE `product_relation`(
  `product_id` Int(11) NOT NULL,
  `relation_id` Int(11) NOT NULL,
  `is_del` ENUM("n", "y") NOT NULL,
 PRIMARY KEY (`product_id`,`relation_id`)
) ENGINE = InnoDB;


Какие индексы строить в том или ином случаем?
Нужен ли составной UNIQUE INDEX (`product_id`,`relation_id`) или INDEX (`product_id`) для первой схемы?
Нужен ли FOREIGN KEY, если данные из таблиц никогда не удаляются (ставится пометка is_del = "y")?

Спасибо)
  • Вопрос задан
  • 5319 просмотров
Подписаться 6 Оценить 2 комментария
Решения вопроса 2
Melkij
@Melkij
PostgreSQL DBA
Индексы строятся только под запросы. Если запросов, использующих этот индекс нет - то индекс только мешает работе.

Констрейты (fk и unique) - ставятся в зависимости от требования к данным, при этом мешают программисту делать глупости. Потому их лучше всегда ставить, пока не будет сделан обоснованный вывод, что их надо убрать.

По схемам - вторая будет оптимальнее. Меньше объём рабочего набора - меньше i/o. В большинстве случаев, судя по всему, будет поиск по первичному ключу - ещё меньше i/o, т.к. в innodb данные кластеризованы по первичному ключу.
И скорей всего забыли указать unsigned, это ведь наверняка ссылки на автоинкременты.
Ответ написан
Комментировать
@SashaSkot
Специалист широкого профиля
По индексам в MySQL есть хорошая статься тут.
Как пишут выше - внешние ключи нужны для сохранения связей между таблицей и предотвращения разрыва связей объектов. Если кто-то удали строчку из одной таблицы, а id о ней останется в другой - у вас будет бедлам и хаос, куча мусора и с разрастанием таблиц - просидание производительности. Про это можно прочитать тут.

Первую схему забудьте для связей многие-ко-многим.
Ответ написан
Пригласить эксперта
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы