Valentyn PidburtnyiЕсть таблица Goods(id int, name varchar(255)). По полю ID построен индекс.
А также процедура:

create procedure __temp(_id int)
define _a int; let _a = 1;
insert into zTable(id, name) select id, name from Goods where id = _id or _a = 0;
insert into zTable(id, name) select id, name from Goods where id = _id or 1 = 0;
end procedure;


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

Что можно сделать? (в смысле как заставить использовать индекс).

При выроботке плана выполниния запроса оценивается
результат условия 'or' и если есть предположение,
что если хоть один из операндов принимает значение ложь
то использование индекса смысла не имеет.
В вашем сучае _a = 0; всегда ложно.
Ситуацию можно сравнить с ситуацией когда в таблице
существует поле _a и оно не входит ни в один из индексов.

Тогда ситуация сразу станет прозрачной, а поведение оптимизатора
соответствующим логике.

Резюме:
Я подозреваю, что оптимизатор не видит разницы между полем
и переменной.

vasilis
Я что то не понял твоей логики...
Если "_a = 0; всегда ложно", то что тогда можно сказать о 1=0 ?
Вроде, как все наоборот, по выражению _a = 0 оптимизатор еще ничего не знает (обрабатывается как константа = переменная), так как подстановка конкретного значения произойдет уже на этапе выполнения, после построения плана запроса. А вот во втором случае 1=0 всегда ложно и остается только один фильтр, для которого индекс используется почти всегда (за редким исключением).

Да действительно, что то я сам запутался :(.

vasilis[quot onstatЯ подозреваю, что оптимизатор не видит разницы между полем
и переменной.

Подозреваю, что видит :)
При анализе "поле_таблицы" > 5 оптимизатор уже имеет статистику(если она собиралась), по которой он может определить избирательность данного фильтра и предположить примерное кол-во строк в выборке, заодно и оценив применимость индекса, (если он есть).
При анализе же "поле_таблицы" > "переменная" оптимизатор не может знать заранее все значения переменной, соответственно и построение плана может быть совершенно другим.Тут , кстати, оптимизатор может построить план, удовлетворяющий первому значению переменной, что потом может вылезти боком на других значениях...
При анализе условия "переменная" > 5 оптимизатор тоже ничего не может сказать заранее, какой (ложь или истина) будет результат, соответственно и проверять надо будет все строки таблицы[/quot]

Здесь имелось ввиду, что если есть условие 'or'
с участием двух полей, и только одно из них индексировано.
Множество всех значений удовлетворяющих условию where
будет зависеть от обоих полей.
То есть, по не индксированному полю всеравно нужно будет
искать перебором всех значений таблицы.

В случае же с константами в условии where, константное выражение,
может быть вычислено до начала работы оптимизатора.

Все это только предположение.