Lumixи теперь билдер sql-запросов, когда встречает эту комбинацию в запросе, то заменяет её на fif_1 = 1
это вам кто сказал?
Если бы вы сделали вычисляемое поле, - то да, у оптимизатора была бы возможность свернуть 4 проверки разных полей в проверку одного вычисляемого поля, да и то не факт что на это хватило бы времени.

Но в MySQL вычисляемых полей нет, поэтому замену 4х проверок на одну вам придется делать самостоятельно. Насколько я понял, вы хотите как раз автоматизации замены - тогда ответ "нет".

По той части вопроса, в которой вы хотите комбинировать условия фильтра - оптимизатор строит план выполнения запроса на основе кучи статистических данных о содержимом таблиц, и вполне может не согласиться с заявленным в запросе порядком обработки, посчитав его более затратным по ресурсам, и выполнив "свой" вариант обработки. Именно поэтому SQL является деклартивным, а не операционным языком: в запросе указывается, что требуется сделать.
Как сделать затребованное оптимальным с точки зрения ресурсов сервера способом - определяет сама СУБД.

Это же справедливо и при использовании VIEW: определение VIEW подставляется в соответствующее место запроса, и уже после этого производится построение оптимального плана выполнения "развернутого" запроса (да еще и время на построение плана ограничено).

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

LumixCygapb-007поэтому замену 4х проверок на одну вам придется делать самостоятельно. Насколько я понял, вы хотите как раз автоматизации замены - тогда ответ "нет".


ложная тревога
все юнитам вернуться в места постоянной дислокации)))

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

По 1.а - если индекс по Х более селективен, его логичнее использовать раньше отбора по fif_1, но селективность может ухудшаться (или улучшаться) при увеличении числа строк.
Именно об этом основная часть моего ответа.

Lumix,

Посмотрите Определяем порядок столбцов в составном индексе

miksoft,

а я почему-то думал, что пересечение индексов работает только для AND, типа есть intersect - и хватит...

А в доку лезть поленился :)

Спасибо:)

Lumixединственное я сейчас пока не нашел ответа, считаются ли селект в селекте одним селектом или внутренний селект считается самостоятельным селектом и поэтому через вложенные селекты можно замутить в одном селекте использование двух индексов

Как мне представляется, на первом этапе компиляции запрос раскладывается на кирпичики элементарных действий, а затем, на втором этапе, оптимизатор, используя свой набор правил оптимизации, начинает корежить черновой план выполнения с учетом накопленной на момент оптимизации запроса статистики по индексам и значениям полей таблиц из запроса, добиваясь минимальной ожидаемой стоимости выполнения за отведенное на компиляцию запроса время. И сформированный в итоге план выполнения может значительно отличаться от ожидаемого при написании запроса. А может и совпадать, если статистика соответствует ожиданиям:)

Это я к тому, что предоставьте оптимизатору возможность выбора, добавив всевозможные индексы на этапе тестирования (самый простой, универсальный, но и самый медленный план, который можно выбрать практически всегда, - последовательное чтение всех строк таблицы в порядке извлечения их из хранилища). Но и не забывайте, что чем больше индексов - тем больше места требуется на диске и тем дольше изменения таблицы (все индексы нужно перестроить при каждом INSERT/DELETE, а некоторые и при UPDATE).

Предоставив всевозможные индексы, можно оценить поведение оптимизатора, разрешая или запрещая некоторые из созданных индексов через index_hint

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

Хотя насчет оптимизатора MySQL - могу только предполагать...