> Вот за что и не люблю академические поделки - так это за
> это самое "а баба яга против". Во-первых - идеальных оптимизаторов не
> бывает, баги есть у всех, угу. Во-вторых - в случае БД
> (очень динамично меняющеся структуры) весь оптимизатор представляет собой сплошную эмпирику,
> призванную на кофейной гуще угадывать, как конкретный запрос скоррелирует с размещением
> данных. Кое-у-кого (MSSQL) - вообще стохастические алгоритмы используются, и оптимизатор
> плохо предсказуем. В целом все оптимизаторы затачиваются под усредненный профиль, и
> специфику конкретных приложений могут не понять.А специфика конкретных приложений затачивается уже указанием индексов. Если вот это надо быстро то стоит делать материализированный виев.
> Поэтому имеем то, что имеем - возможность обойти оптимизатор - нужна. По
> двум причинам:
> 1. Если я точно знаю, что мой набор данных быстрее соберется именно
> вот с этого вот боку, а иные варианты проектирования - еще
> хуже в обозримом круге вариантов - то зачем мне все усилия
> оптимизатора по приоритизации таблиц и индексов, к примеру? Тем более, что
> он часто ошибается.
В MySQL часто. В PostgreSQL существенно реже.
> И если в некой СУБД этого делать не хотят по "академическим" мотивам,
> навязывая свой паттерн мышления - я просто не буду применять эту
> СУБД нигде, за исключением случаев, когда что-то к ней гвоздями прибито.
> Из-за недостаточной гибкости. Возникнуть же ситуация может в любой момент.
Да сколько угодно. Проблема только в том что MySQL все еще хуже по фичам чем PostgreSQL ивсе так же плохо держит нагрузку.
> Если честно - в заббиксе транзакции ничем не помогут производительности. Это так,
> попутный вывод на основе анализа его запросов при оптимизации. Наоборот -
> могут усугубить - за счет длительного блокирования.
Какого еще длительного блокирования? Ну пишу я себе там в потоке ни у ладно. Блокировка таблицы в MySQL возникает только при самом высоком уровне изоляции или при применении MyISAM. А вот его применять пожалуй не стоит.
