Насколько я понимаю, большинство оптимизаторов запросов «основаны на затратах». Другие «основаны на правилах», или я считаю, что они называют это «Основанный на синтаксисе». Итак, что лучше всего оптимизировать синтаксис операторов 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 для TB? Оптимизатор SE основан на стоимости, когда он имеет достаточно данных, но не использует такие дистрибутивы, как оптимизатор IDS.
IDS'ROWID не является INT, это логический адрес оставшейся страницы строки сдвинул 8 бит и номер слота на странице, содержащей данные строки.
оптимизатор IDS»является стоимость оптимизатор, который использует данные о глубине индекса и ширины, количество строк, количество страниц и распределения данных созданы обновление статистики среднего и высокого уровня, чтобы решить , какой путь запроса наименее дорогой, но нет ранжирования заявлений?
Я думаю, что Oracle использует значения HEX для ROWID. Слишком плохо ROWID нельзя часто использовать, так как строки ROWID могут меняться. Таким образом, возможно, ROWID может использоваться оптимизатором в качестве счетчика для отчета о прогрессе запроса? Идея, о которой я упоминал в моем вопросе «Начать просмотр результатов запроса до завершения запроса»? Я чувствую, что было бы непросто сообщить о прогрессе запроса во время обработки, возможно, за счет некоторых незначительных накладных расходов, но было бы неплохо узнать заранее: «Google-подобная» оценка количества строк соответствует критерии запроса, отображать его прогресс каждые 100, 200, 500 или 1000 строк, дают пользователям возможность отменить его в любое время и начать отображать квалификационные строки по мере их ввода в текущий список, в то время как он продолжает поиск? .. Это это всего лишь один пример, возможно, мы могли бы подумать о других опрятных/полезных функциях, ингридиенты более или менее существуют.
Возможно, мы сможем уточнить каждый запрос с большей детализацией, чем в настоящее время? Запросы OLTP, как правило, в основном статичны и предопределены. «What-if» больше OLAP, поэтому давайте попробуем добавить к нему больше контроля и интеллекта? Поэтому, имея возможность более точно контролировать, а не просто «намек/влияние», оптимизатор - это то, что нужно. Затем мы можем иметь более динамические операторы SELECT для конкретных ситуаций! Возможно, даже сообщите IDS, чтобы читать блоки индексов сразу, а не по одному, и т. Д. И т. Д.
В одном вопросе много вопросов - для коммерческих продуктов внутренняя работа оптимизаторов запросов остается внутренней информацией, поскольку она является частью IP-адреса продукта. – Andrew