MySQL - структура таблицы

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

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

Тем более, при частом обновлении.

Basilisk, имеет смысл денормировать все поля или только те, которые обновляются?

вполне достаточно только те, которые обновляются

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

Упрощенный пример - у вас есть миллиард заказов, для каждой строки заказа в таблице "Позиции заказа" есть количество и цена, при выборке вы умножаете количество на цену и получаете сумму по позиции.

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

Другой пример - в самой таблице "Заказы" у вас всегда будет поле "Общая сумма заказа" - чтобы сэкономить на join'ах и не подцеплять позиции заказа каждый раз, когда вам понадобится получить Номер, Дату и Сумму заказа.

А по второму вопросу что скажете?

Если сейчас есть составной индекс f1-f2-f3-f4 в одной таблице, то при разбиении на несколько таблиц и последующих join'ах, как будут индексы работать? Время выборки не увеличится?

Сначала join присоединяет соответствующую таблицу, а потом фильтрация по условиям происходит или сначала фильтрация, а потом join?

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

Примари кей состоит из одного поля или составной? (С составным могут быть нюансы с дисковой нагрузкой при инсертах)

Еще можно посмотреть, нужны ли все десять индексов.

Например, тут можно погонять тесты с составным индексом на три поля: f1-f2-f3

Возможно разница по времени выполнения будет небольшая и не перекроет накладные расходы по поддержке индекса f1-f2-f3-f4 (при частых UPDATE/INSERT)

Если есть возможность, то часто изменяемые данные желательно вынести в отдельную таблицу. Т.к. при каждом UPDATE или INSERT сбрасывеатся query_cache(для конкретной таблицы) и он ставовится бесполезен.

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

Какие еще методы есть? Только накапливать изменения и одним коммитом их забрасывать в таблицу?

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

Зачем вам индекс?

Выложите уже схему БД и заодно - что туда пишете, зачем вам советы "как вылечить больного без больного"?

Еще вариант - для данных с большой динамикой и структурой, которой можно пожертвовать - использовать NoSQL, вроде redis или mongo.

Выкосить лишние индексы, если есть. Скорректировать отдачу кешированием конечных результатов. Выкосить лишние записи, если возможно.