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

Индекс это вид упорядочной записи, то есть да, он может разрастись, если будет расти и сама база, если база не будет расти, не будут расти и индексы.

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

Желательно делать индексы по столбцам, по которым идет WHERE и ORDER BY (операции фильтрации и сортировки).

Если в запросе два WHERE то нужно делать составные индексы.

На все столбцы делать индексы не нужно.

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

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

Индексы на все столбцы вообще ересь какая то. В запросе БД может использовать только 1 индекс, всегда только один, и выбирает максимально оптимальный. А составные должны быть точто в таком же порядке как и в выражения where. По факту получается, что у вас беда с архитектурой БД, потому что в теории (ведь это реляционная БД) вам не должно понадобиться такое количество индексов в рамкох одной таблицы. Хотя фиг его знает что у вас там за приложение.

А вот перестраивать индексы в большой таблице при insert/update/delete может стать огромной проблемой

возможно оптимальнее было бы разбить БД

а вообще тестируйте. смотрите как быстрее и найдете свое

+ в гугле куча опыта есть уже, читайте

Приложение: представьте себе таблицу с параметрами товаров (как я выше писал их сейчас 14), юзер видит эту таблицу у себя в браузере. Юзеру дается возможность фильтровать и/или сортировать по любому столбцу. Я так считаю, что в данном случае на каждый такой столбец нужно по индексу.

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

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

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

И мы получим в 18 раз большую таблицу. Правда с одним индексом, что хорошо, но при добавлении-изменении-удалении товара надо будет править 19 строк вместо одной, что плохо. И это решение будет нормальным, если джоинов мало (например фильтр по одному-двум-трем параметрам). А если фильтр по 10 параметрам? База загнется от такого запроса.

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