MySQL: индексы почти на каждый столбец - это плохо?

+1

Правда, есть такое понятие, как слияние индексов.

Ну и не всегда планировщик выбирает оптимальный индекс.

Это не так. :)

Что это за такая теория? :)

+1.

Даже в относительно маленькой таблице (2 ГБ) инсерты начинают тупить при добавлении каждого дополнительного индекса.

---------- Добавлено 25.01.2017 в 09:59 ----------

Сколько записей в таблице?

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

Смотрите, короче, EXPLAIN самых частых запросов.

Товары, я так понял, все однотипные?

Характеристики однотипных товаров можно хранить в одной таблице.

Характеристики же разнотипных товаров нужно выносить в отделюную таблицу.

А также почитайте о таком понятии, как cardinality индекса.

Если поле принимает только 2 значения, то индекс ставить на него смысла нету.

Индексы нужно ставить на поля, по которым происходят JOIN.

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

В итоге в таблице товаров будет вместо 18 полей - пусто, а править таблицу много-ко-многим не так и сложно и там всего один индекс будет.

Где вы тут увидели в 18 раз большую таблицу?

---------- Добавлено 25.01.2017 в 12:14 ----------

ну по объему спорно. вместо 18 полей и 18 индексов, всего то таблица с 3 полями и одним индексом. Да по количеству записей она будет больше, но с другой стороны - поиск и запись в такую таблицу будут работать намного шустрее. Так что вопрос по количеству открыт.

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

Причем поиск (фильтры) при такой раскладке намного проще устроить - сразу есть таблица откуда имена и id этих фильтров брать и не нужно таблицу товаров дергать лишний раз.

Я имел ввиду количество строк. Мне такое решение с вынесом атрибутов в отдельную таблицу не нравится.

А я бы вообще пошел другим путем:

1) Параметры товаров оставил бы в самих товарах, но без индексов - так проще и удобней для большинства операций с товарами.

2) Выборку товаров с сортировкой и фильтрацией вынес бы в отдельную независимую систему - отдельный фронтэнд например на elasticsearch.

Ясно, спасибо! А если не два значения, а, допустим, 6? У меня есть несколько INT колонок с таким количеством вариантов (включая вариант Null).

Про кардиналити почитаю, спасибо!

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

Все может быть. Групп товаров может быть много, у каждой группы свои параметры

Товар 1 - 5 параметров, Товар 2 - 18 параметров (как в примере, но фильтр на 18 параметров в топку), Товар 3 - 7 параметров....

Можно для фильтра таблицу фильтр: ид товара - ид параметра - значение параметра. Рабочий вариант. Другой вариант - для каждого товара своя таблица, каждая из которых может быть сильно меньше таблицы фильтр (и в 18 раз в том числе). В результате моих тестов, для что то около 50 групп товаров, динамические таблицы на каждый из них пока впереди.

Хотя можно и ниже опуститься 50 таблиц товар + 50 таблиц фильтр😂

Мысль ясна. Однако, юзер может захотеть фильтрануть или поискать и по этим колонкам (с малым количеством возможных вариантов). Я так понимаю, при больших размерах таблицы такие выборки без индексов могут стать проблемой?

Если у вас миллион товаров, то это конечно может стать проблемой.

А вообще если у вас самопис, то я бы вообще не извращался со структурой хранения товаров и его параметров. Если вас наиболее устраивает хранение параметров товара в одной таблице с товаром (в виде полей), то так и оставляйте. Ведь так работать с товаром намного удобней и эффективней: большинство операций с товаром будет выполняться максимально быстро и просто - одним запросом. Логика работы с товарами также будет максимально простой, в отличие от дробления товара на кучу таблиц с резким усложнением логики работы с товарами.

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

Хм, как раз в самописи можно настроить все как нужно :)

Вот Вы и сами ниже насоветовали. :)