>> Слабо представляю надобность использования движка InnoDB без внешних ключей.
> Не стоит исключать возможность создания таблиц иннодб просто по умолчанию. Либо по
> незнанию.давайте не будем бредить на эту тему.
>> К тому же Вами не раскрыта тема, как переезд (со значительными затратами)
>> с одного железа на другое поможет в решении заданного вопроса.
> Ну, как бы, увеличение иопсов с 400 (для сказей 15 крпм) до
> полумиллиона весьма благотворно влияет на скорость выполнения запросов. Потому что боттлнеком
> мускля является именно диск, причем не по скорости чтения/записи, а по
> иопсам.
тем не менее тема применения SSD именно для этой задачи до сих пор не раскрыта. и не будет/не_может_быть раскрыта - нет достоверных данных данных для таких выкладок.
>> исключение OR выражений - булева алгебра рулит
> И как прикажете исключать OR из запросов? Что-то я сомневаюсь, что юнион
> двух селектов эффективнее одного селекта с логическим "или".
union - это не OR в where выражении. Вам видисо стоит вообще про SQL почитать. Про конкретный движок ДБ пока помолчу.
>> - постройка и оптимизация индексов для запросов
> База без нужных индексов - не база :)
>> - последняя линия обороны - использование VIEW, временных таблиц и ОЗУ-движков
> Про представления забудьте. Никакого выигрыша по скорострельности они не дают, реализуются
> они подзапросами, и задача их совершенно другая - ограничение прав доступа
> и повышение понимабельности структуры данных человеком. Производительность на вьюшках
> в лучшем случае - не ниже.
вот именно - чтобы ручки-недоручки спрашивали VIEW, которые оптимизированы на работы с индексами. К сожалению это только в простейшем случае возможно - ибо любая выборка по VIEW индексы уже не использует (давно правда этим не интерисовался - может уже и не так - возможность реализации анализировать не хочу)
> Движок мускля сам создаст все нужные временные таблицы для запроса. Если монолитный
> запрос тормозит, а два запроса, общающиеся через временную таблицу, не тормозят,
> значит монолитный запрос кривой.
угу. или надо учитывать блокировки, которые один сложный запрос делает или различных два подряд. и управлять уровнями изоляции транзакций. чтобы результат в конце концов был одним и тем же.
> ОЗУ-движки - вполне хорошо, когда железо позволяет насовать достаточно планок памяти. И
> когда есть достаточно мощный УПС, который продержит систему онлайн, пока она
> сливает из МЕМ-таблицы на диск. Но в большинстве случаев отдельное устройство
> со своими слотами под ДДР, со своей батареей и собственным, монопольно
> используемым накопителем оказывается существенно дешевле.
>> процедуркой все insert|delete|edit делать
> В мускле это называется UPDATE.
спасибо Кеп. Даже в SQL-92 (уже довольно старом по нынешним меркам, но рекомендую Вам к прочтению) это именно так, как Вы сказали и называется.
Вариант для распечатки
