Query
Текст выполненного запроса. Также указывает, был ли установлен (например, оператором SET OPTIMIZATION) уровень оптимизации HIGH.

Если был установлен уровень оптимизации LOW, вывод SET EXPLAIN будет включать следующую первую строку (используются только заглавные буквы):
QUERY:{LOW}

Если был установлен уровень оптимизации HIGH, вывод SET EXPLAIN будет включать следующую первую строку (используются только заглавные буквы):
QUERY:

Directives followed
Списки директив, указанных для выполнения запроса.
Если в директиве была синтаксическая ошибка, эта директива игнорируется при обработке запроса. В этом случае вывод будет содержать такое указание: DIRECTIVES NOT FOLLOWED помимо DIRECTIVES FOLLOWED.

Estimated Cost
Оценка затрат (работ) на выполнение запроса.
При сравнении одного плана выполнения запроса с другим оптимизатор использует оценки затрат на выполнение запроса. Оценки затрат - это числовое значение, назначаемое оптимизатором выбранному методу доступа. Оценка затрат не преобразуется непосредственно во время выполнения запроса и не может использоваться для сравнения разных запросов. Однако эту оценку можно использовать для сравнения изменений, сделанных в одном и том же запросе.
Если запрос включает подзапрос, то указываются два описания оценки затрат; при этом описание оценки затрат запроса включает описание оценки затрат подзапроса. Оценка затрат подзапроса отображается таким образом, чтобы вы увидели, что эти затраты связаны с подзапросом.

Estimated # of Rows Returned
Оценка числа строк, которые должны быть выданы запросом.
Эта оценка основывается на описаниях, хранящихся в таблицах системного каталога. (если это число отличается от реального количества возвращаемых запросом строк в несколько раз, то по одному из участвовавших в запросе полей собрана неточная статистика)

Numbered List
Порядок, в котором производится обращение к таблицам согласно используемому методу доступа (по индексу или последовательное сканирование).
Если запрос использует наследуемость таблиц, то все подтаблицы супертаблицы перечисляются в том порядке, в котором производилось к ним обращение.

Index Keys
Столбцы, используемые как фильтры или индексы; указывается имя столбца, используемого в плане для чтения по индексу, или фильтр.
Обозначение (Key Only) указывает, что все нужные столбцы входят в состав ключа индекса; поэтому вместо чтения строк реальной таблицы можно было бы использовать чтение только ключей индекса (key-only read).
Обозначение (Lower Index Filter) указывает значение ключа, с которого начинается чтение по индексу. Если условие фильтра содержит несколько значений, то может быть выдано обозначение (Upper Index Filter); оно указывает значение ключа, на котором останавливается чтение по индексу.

Join Method
Если запрос содержит соединение двух таблиц, то в верхней части вывода для этого запроса указывается метод соединения этих таблиц, используемый оптимизатором - Nested Loop (метод вложенного цикла) или Dynamic Hash (динамическое хеширование).
Если запрос содержит динамическое соединение двух таблиц, а вывод также содержит обозначение (Build Outer), то это обозначает, что хэш-таблица создана для первой указанной таблицы (которая называется базовой таблицей).
Если обозначение (Build Outer) отсутствует, то это означает, что хэш-таблица создана для второй указанной таблицы.


-----------------------------------------------------------
Хочу есть. myinformix

2316 row(s) retrieved
Estimated # of Rows Returned: 8639047

такая ошибка (на 4-е порядка) говорит о том что статистики распрелеления значений в поле rdel не собрана , правильное решение проблемы update statistics.

Valentyn P."high" - нежная весчь. Щупать надо осторожно.:)
Это бывает очень редко, это исключение.
Т.е. годами точим запросы под low потом переходим на "high", планы поехали. Тоже самое будет если сделать в обратном порядке, только вероятность что планы поедут не туда она в этом случае выше сильно выше.


Valentyn P.
Да нет, во втором случае похоже, что таблица выбирается в отсортированном порядке по колонке r_key, после чего накладывается фильтр по r_del.
Я подозреваю, что если выбирать данные по r_del, запихивать их во временный файл и там сортировать - будет медленнее и стоимость повысится.:)Нам показали что отсортировать надо 2000 записей, диск не нужен, достаточно l2 кеша процессора.
Но информикс думает (т.к. нет статистика) что отсортировать надо 8млн, а в таблице всего 25млн, поэтому такой план.

aist-pskпрограммист сказал - что указывать оптимизатору какой индекс использовать - моветон
я простой админ , но я вижу что после update statisics high talbe (или база) - план тестового запроса - пришёл в норму = количество выбранного = ожидаемому количеству

а почему high нежное ?
чего опасного там ?Нет там ничего опасного. Мы заплатили за информикс, мы заплатили за оптимизатор, за статистику, давайте пользоваться тем за что уже заплачено. Зачем руками писать хинты, пусть компьютер выполняет рутинную работу.

У меня в машине роботизированная коробка передач, можно ездить переключая вручную, можно на автомате. 99% автомат делает то что надо, в 1% случаев я понижаю или повышаю вручную, но этот 1% не повод ездить в ручном режиме 100% времени.

Valentyn P.На первый взгляд, такая статистика, собранная по неиндексным полям - абсолютное зло, ибо серьезно увеличит объем данных, которые будут у оптимизатора под рукой, но никогда не приведут к реальному изменению плана. Ибо менять в плане нечего:)
Я не призываю делать high на всю базу. Индексированные поля, 5-10% строк на таблицах с млн. строк, иногда нужен гибкий график, на некоторые таблицы раз в неделю, а на другие 5 раз в день.

aist-pskитого :

раз в неделю(месяц) update statistics high
в остальное время low

Александрнеправильно.