День добрый.
есть условие запроса


при этом все поля индексированны но ясен пень индекс по field5  сервером не используется.
вопрос: как поступает сервер - понимает ли он что издержки выборки по условию field5 самые значимые и соответственно делает ли предварительное урезонное подмножество с условиями field1 - field 4 и только потом применяет условие field 5 или хреначит все пять условий для каждой записи всей таблицы?
Пытался сравнить время возврата view этого запроса с запросом(условие по field5) из подзапроса(условия field1 по field4), время отклика очень разное ввиду крайне неравномерной загрузки сервера ( сидят 2 аксапты) - ничего не понятно.
Прошу простого краткого ответа без ссылок на просмотр плана или гугла

И да, и нет. Но он точно понимает, что индекс использовать не удастся.


Он выберет подсет записей, используя один из четырёх индексов - скорее всего наиболее селективный из списка (1, 2, 4),- а остальные условия будет проверять прямым сканированием. А при небольшом количестве записей в таблице может вообще отказаться от использования индексов и сканировать всю таблицу.


Из подзапроса - дольше. И чем больше по размеру запись, и чем ниже селективность подзапроса, тем оно заметнее.

Точный ответ на вопрос

Можно увидеть только в плане.


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

Для этого запроса, скорее всего, наиболее эффективно может быть использован составной индекс  по (field1,field4,field3[,....]).

Говорю "скорее всего" потому что не уверен на счет того, как будет работать отбор по field4.  Если бы в предикате по field4 было строгое равенство val1, отбор бы происходил примерно так: ищется точное соответствие field1 = :val1 and field4=:val1 and field3=:val1, затем бы сканировался диапазон, последовательным перебором, пока стрельнет условие field1 != :val1 or field4!=:val1 or field3>:val2. 
Что будет происходить, когда у нас значение field4 отбирается не однозначно - не зна. Скорее всего, для заведомо известного количества значений (в данном случе - двух), индекс сможет быть использован, но для уверенности, надо смотреть в плане.

Если не сможет, надо смотреть какую селективность смогут обеспечить индексы по (field1,field3[,....]), (field1,field4[,....]) и выбрать то, что даст большую селективность.

Это сообщение отредактировал(а) Zloxa - 1.6.2012, 16:07

Практика - критерий истины.   
Для оракла
DDL:

план:

Здесь мы видим, что все поля, пречисленные в индексе, участвуют в отборе.
на field5, field2, предикаты по которым в принципе не позволяют использовать индексный доступ, сверху отбора накладывается фильтр.
Сверху накладывается фильтр :val3 < :val4. Это условие уже исключено условиями, перечисленными в предикатах доступа. Наверняка здесь фильтр нужен для того, чтобы даже не пытаться выполнять отбор, если это условие стрельнет.

Поменяем порядок следования полей в индексе:

план:

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

Это сообщение отредактировал(а) Zloxa - 1.6.2012, 16:41

Прежде чем принимать решение о построении такого большого составного индекса, следует определиться а поможет ли он вообще. Можно расчитать фактор селективности


Чем ближе полученное значение будет к еденице, тем меньше смысла в построении такого индекса. Есть мнение, что полное сканирование, в общем случае, будет эффективнее индексного доступа, если фактор селективности превышает 0.2

наверно все-таки к нулю?


то есть использование этого коэф.даст возможность принять решение о том - стоит ли заливать составной индекс?
И еще - я правильно понял что составной индекс по field1-field4 даст некоторый выигрыш при формировании подсета?

Именно к единице.


Очень приблизительно. Практические измерения надёжнее.


Может, но не обязан.

Именно в этой последовательности. Мне казалось я это очень наглядно показал :facepalm

Добавлено через 7 минут и 39 секунд

Да


Да


Да