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