On 12/09/2011 07:42 PM, Энтри_N3 wrote:

> select *
> from table_1
> where (field_1 IN ('значение_1','значение_2','значение_3','значение_4')
> or field_2 IN ('значение_1','значение_2','значение_3','значение_4')
> or field_3 IN ('значение_1','значение_2','значение_3','значение_4')
> or field_4 IN ('значение_1','значение_2','значение_3','значение_4')
> )

1) Если тебе надо проверять наличие значения в нескольких полях, как тут,
-- это ошибки в проектировании БД, нарушение 1ой нормальной формы
Рецепт - редизайт, эти поля пойдут в отдельную дочернюю таблицу 1:N с данной
таблицей.

После "лечения" запрос будет примерно таким:

select *
from table_1 t1
join table_1_fields t1f on t1f.t1pk = t1.pk
where t1f.field IN ('значение_1','значение_2','значение_3','значение_4')

2) Избавляться от IN ('значение_1','значение_2','значение_3','значение_4')
в принципе уже не обязательно, если значений в IN немного.
Но если хочется -- делается временная таблица "список проверяемых значений"
(check_list) с одним полем -- field, оно же бывшее field1...fieldN
и идентификатором сессии пользователя user_session_id.

И запрос превращается в

select *
from table_1 t1
join table_1_fields t1f on t1f.t1pk = t1.pk
join check_list chl on chl.field = t1f.field
where chl.user_session_id = curent_user_session_id()

Для правильной работы этого запроса в любых условиях, даже когда
оптимизатор не догадывается, что check_list-- это таблица-фильтр,
нужно форсануть план, чтобы таблица check_list была бы первой в
запросе, т.е. по уму данный запрос должен выполняться
"снизу вверх" как он у меня тут написан.
Если оптимизатор догадается сам, то и хорошо.

На самом деле ещё раз, вовсе не обязательно делать второй шаг,
поскольку совсем не очевидно, что будет оптимизироваться лучше,
запрос после шага 1, или после шага 2.
Posted via ActualForum NNTP Server 1.5

> Для начала скажу, что корежить структуру для одного запроса может оказаться
> плохой идеей.

А я скажу для продолжения, что если это наруш. 1НФ, то оно будет сказываться
НА ВСЕХ запросах, затрагивающих это поле. Этот запрос -- только первая ласточка.
Для хороших запросов БД должна быть хорошо спроектирована. Так что чем раньше --
тем лучше.

> Далее, оптимизация таких запросов сильно зависит от данных. Какой процент
> таблицы возвращается запросом? Какое количество полей пустые (содержат null).

Да ладно, тут -то как раз всё ясно.
N полей в OR, и M значений в IN,
получается либо делать table scan, либо
выполнять N * M позиционирований по индексу по полю field1..fieldN
Это даже тут уже 16.

Если бы тут что-то зависело от данных, т.е. распределение данных было
бы плохое, невыгодное для индексирования, было бы всё равно, как этот
запрос выполнялся бы -- в любом случае это было бы медленно.

> Как быстро выполняется простые запросы
>
> select * from table_1where field_1IN ('значение_1' )

logN (размер таблицы).
Если есть индекс. Если нет -- автор бы не спрашивал.

> Смотрите сами: если поля проиндексированы ваш запрос дает соединение 4*4=16
> индексных сканов. В таких условиях *один* полный скан (или индексный скан по
> другому индексу) легко может оказаться предпочтительнее.

Ну вот, понимаешь же, а чего тогда про данные тут выспрашивал?
Posted via ActualForum NNTP Server 1.5