Влияет ли число столбцов таблицы MySQL на производительность?

Question

[freeeeez]

У меня в MySQL таблице товаров 100 столбцов с данным, при этом это уже сокращенный вариант, так как где-то 50 было разнесено по таблицам с дополнительными характеристиками товаров. На сколько это будет влиять на время чтения/записи в дальнейшем, когда будет допустим 1 000 000 позиций? 100 000 000 позиций? Разносить остальные данные по дополнительным таблицам или без разницы и оставить так?

Comments

[Lander]

Про нормализацию сначала почитайте. Думается мне, что у вас что то не так, если у вас 100 столбцов в таблице.

[DevMan]

freeeeez теги к вопросам не для того, чтоб их ставить от балды.

[freeeeez]

DevMan: сорян

[d'Ivan]

А колонки там случайно не называются col1, col2, col3, ...?

[freeeeez]

Роман Мирр: нет, типо того: weight, length, width, height, price, tax и т.п.

[d'Ivan]

freeeeez: обязателен ли поиск/фильтрация по этим полям?

[freeeeez]

Роман Мирр: да, по каждому полю должен быть поиск, причем в некоторых полях содержатся ID-шники из других таблиц и по ним тоже выборка идет

[d'Ivan]

freeeeez: попробуй разобраться с о структурой таблиц EAV, описанной в статье из моего ответа.
Суть состоит в том, чтобы атрибуты данных росли не вширь (в колонки), а вниз.

Answer 1

[xmoonlight]

У меня в MySQL таблице товаров 100 столбцов с данными

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

В итоге: будет удобно создавать фасетный фильтр (для поиска товаров с определённым набором) и максимально сделать индексацию через ID-полей внутри базы.

Comments

[freeeeez]

уже по отдельным таблицам разнесена часть данных, если делать по всем то останется столбцов 15-20 и столько же дополнительных таблиц, что мне кажется тоже не хорошо

[xmoonlight]

freeeeez: тогда 2 варианта mysql >=5.7 + json или noSQL-база...

Answer 2

[d'Ivan]

Нет, кластеры не обязательно.
Стоит обратить внимание на колоночные СУБД, решающие проблему оптимального хранения и доступа к данным при большом множестве колонок.
MonetDB, Druid или, например, развивающийся продукт MariaDB ColumnStore (поддерживается полный SQL) как продолжение развития InfiniDB.

Добавлено позже:
Есть одна статья, рассказывающая о способах хранения данных в таблицах в традиционных СУБД:
Структура таблиц для каталога товаров интернет-магазина

EAV расшифровывается как Entity–attribute–value или по-русски: объект-атрибут-значение. Она представляет собой модель данных для описания сущностей, в которых количество атрибутов (свойств, параметров) может быть потенциально большим.

Comments

[d'Ivan]

Александр +: архитектурные проблемы нужно решать, а не откладывать на потом.
Насколько я понял, при работе с MariaDB ColumnStore ничего не меняется с точки зрения подключения к СУБД: остаётся та же строка подключения, тот же драйвер, что и к MySQL. Во всяком случае, имеет смысл проверить этот вариант.
(комментарий полезен и для freeeeez ).