> Слабо представляю надобность использования движка InnoDB без внешних ключей.

Не стоит исключать возможность создания таблиц иннодб просто по умолчанию. Либо по незнанию.

> К тому же Вами не раскрыта тема, как переезд (со значительными затратами)
> с одного железа на другое поможет в решении заданного вопроса.

Ну, как бы, увеличение иопсов с 400 (для сказей 15 крпм) до полумиллиона весьма благотворно влияет на скорость выполнения запросов. Потому что боттлнеком мускля является именно диск, причем не по скорости чтения/записи, а по иопсам.

> исключение OR выражений - булева алгебра рулит

И как прикажете исключать OR из запросов? Что-то я сомневаюсь, что юнион двух селектов эффективнее одного селекта с логическим "или".

> - постройка и оптимизация индексов для запросов

База без нужных индексов - не база :)

> - последняя линия обороны  - использование VIEW, временных таблиц и ОЗУ-движков

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

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

ОЗУ-движки - вполне хорошо, когда железо позволяет насовать достаточно планок памяти. И когда есть достаточно мощный УПС, который продержит систему онлайн, пока она сливает из МЕМ-таблицы на диск. Но в большинстве случаев отдельное устройство со своими слотами под ДДР, со своей батареей и собственным, монопольно используемым накопителем оказывается существенно дешевле.

> процедуркой все insert|delete|edit делать

В мускле это называется UPDATE.

>> Слабо представляю надобность использования движка InnoDB без внешних ключей.
> Не стоит исключать возможность создания таблиц иннодб просто по умолчанию. Либо по
> незнанию.

давайте не будем бредить на эту тему.

>> К тому же Вами не раскрыта тема, как переезд (со значительными затратами)
>> с одного железа на другое поможет в решении заданного вопроса.
> Ну, как бы, увеличение иопсов с 400 (для сказей 15 крпм) до
> полумиллиона весьма благотворно влияет на скорость выполнения запросов. Потому что боттлнеком
> мускля является именно диск, причем не по скорости чтения/записи, а по
> иопсам.

тем не менее тема применения SSD именно для этой задачи до сих пор не раскрыта. и не будет/не_может_быть раскрыта  - нет достоверных данных данных для таких выкладок.

>> исключение OR выражений - булева алгебра рулит
> И как прикажете исключать OR из запросов? Что-то я сомневаюсь, что юнион
> двух селектов эффективнее одного селекта с логическим "или".

union - это не OR в where выражении. Вам видисо стоит вообще про SQL почитать. Про конкретный движок ДБ пока помолчу.

>> - постройка и оптимизация индексов для запросов
> База без нужных индексов - не база :)
>> - последняя линия обороны  - использование VIEW, временных таблиц и ОЗУ-движков
> Про представления забудьте. Никакого выигрыша по скорострельности они не дают, реализуются
> они подзапросами, и задача их совершенно другая - ограничение прав доступа
> и повышение понимабельности структуры данных человеком. Производительность на вьюшках
> в лучшем случае - не ниже.

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

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

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

> ОЗУ-движки - вполне хорошо, когда железо позволяет насовать достаточно планок памяти. И
> когда есть достаточно мощный УПС, который продержит систему онлайн, пока она
> сливает из МЕМ-таблицы на диск. Но в большинстве случаев отдельное устройство
> со своими слотами под ДДР, со своей батареей и собственным, монопольно
> используемым накопителем оказывается существенно дешевле.
>> процедуркой все insert|delete|edit делать
> В мускле это называется UPDATE.

спасибо Кеп. Даже в SQL-92 (уже довольно старом по нынешним меркам, но рекомендую Вам к прочтению) это именно так, как Вы сказали и называется.