Насколько я понимаю, большинство оптимизаторов запросов основаны на затратах. Другие «основаны на правилах», или я полагаю, они называют это «Синтаксические основы». Итак, каков наилучший способ оптимизировать синтаксис операторов SQL, чтобы помочь оптимизатору получить лучшие результаты?
На некоторые оптимизаторы, основанные на затратах, могут влиять такие «подсказки», как FIRST_ROWS (). Другие предназначены для OLAP. Можно ли узнать более подробную логику о том, как Informix IDS и оптимизаторы SE решают, какой маршрут лучше всего обрабатывать запрос, кроме SET EXPLAIN? Есть ли документация, иллюстрирующая ранжирование операторов SELECT относительно того, какой самый быстрый способ получить доступ к строкам при условии, что они проиндексированы?
Я бы предположил, что "SELECT col FROM table WHERE ROWID = n" является самым быстрым (ранг 1).
Если я не ошибаюсь, ROWID в Informix SE - это SERIAL (INT), который позволяет макс. 2GB Nrows, или, может быть, он использует INT9 для Nrows TB? Оптимизатор SE основан на затратах, когда в нем достаточно данных, но он не использует распределения, подобные оптимизатору IDS.
IDS'ROWID - это не INT, это логический адрес левой страницы строки
сдвинуто 8 бит плюс номер слота на странице, содержащей данные строки.
Оптимизатор IDS - это оптимизатор на основе затрат, использующий данные
о глубине и ширине индекса, количестве строк, количестве страниц и
распределения данных, созданные обновлением статистики MEDIUM и HIGH, чтобы решить
какой путь запроса наименее затратный, но нет ранжирования операторов?
Я думаю, что Oracle использует значения HEX для ROWID. Жаль, что ROWID не может часто использоваться, так как строки ROWID могут измениться. Поэтому, может быть, ROWID может использоваться оптимизатором в качестве счетчика для отчета о ходе выполнения запроса? Идея, которую я упомянул в своем вопросе «Начать просмотр результатов запроса до его завершения»? Я чувствую, что будет не так сложно сообщать о ходе выполнения запроса во время его обработки, возможно, за счет некоторой незначительной накладной нагрузки, но было бы неплохо знать заранее: "Google-подобная" оценка количества встречающихся строк критерии запроса, отображать его ход каждые 100, 200, 500 или 1000 строк, дают пользователям возможность отменить его в любое время и начать отображать соответствующие строки по мере их помещения в текущий список, пока он продолжает поиск? .. Это Это всего лишь один пример, возможно, мы могли бы подумать о других полезных / полезных функций, ингредиенты более или менее там.
Возможно, мы могли бы уточнить каждый запрос с большей детализацией, чем доступно в настоящее время? OLTP-запросы, как правило, в основном статические и предопределенные. «Что, если» больше OLAP, так что давайте попробуем добавить больше контроля и интеллекта к нему? Таким образом, для более точного управления, а не просто «подсказка / влияние» оптимизатор необходим. Тогда мы можем иметь более динамичные операторы SELECT для конкретных ситуаций! Может быть, даже попросить IDS читать блоки индексных узлов за раз вместо одного за другим и т. Д. И т. Д.