для дальнейшей оптимизации?
Я разбираю запрос на мелкие подзапросы и выполняю их.
Смотришь отдельный план для каждого подзапроса?
вначале надо понять КАК читаются данные (индекс или прямое чтение) и потом понять КАК одни наборы данных с другими соединяются (hash join, nested loops, merge join), остальное уже тонкости
Если так чтоб "один раз - и навсегда", и заодно войти в элитный клуб гуру оптимизации SQL запросов - путь один - прочесть от первой до последней страницы книгу Жонатана Льюиса, "Cost-Based Oracle Fundamentals", ссылка: https://www.amazon.com/Cost-Based-Oracle-Fundamentals-Experts-Voice/dp/1590596366. Эта тема - Ваш вопрос, и ответ в виде рекомендации прочитать эту Книгу (да, с большой буквы), многократно поднимался в этом канале, в поиске поищите по строке "Cost Based" - возвращает 8 результатов (наверно после моего сообщения теперь будет 9). Эта книга - отвечает на все вопросы, от начала и до конца, причём Херр Льюис сам по образованию математик, поэтому в книге он объясняет почему cost того или иного запроса отличается чуть ли ни на единицу (типа запрос А - у него cost=4321, а запрос В - у него cost 4322). И вот Льюис рассказывает и объясняет "на пальцах", как оптимизатор высчитывает cost одного и второго запроса, какие формулы используются, какие оптимизации, как одно и другое действие оптимизатора влияет и меняет значение результата оптимизации и значение cost'а. Ну и тд. В общем, я много IT книг прочитал, но эта - не знаю, не припомню другой книги, которая была бы настолько сложной, детальной, фундаментальной что ли. В общем, если осилите (но по-честному, от начала и до конца, и с пониманием каждой главы и каждого примера/формулы, и ещё и каждый пример у себя в тестовой базе погоняете и поймёте/подтвердите, что автор был прав и почему) - думаю, тёмных пятен и непонятных тем в сфере оптимизации SQL запросов у Вас больше не будет
Самое интересное что даже при свежесобранной статистике, Oracle в explain plan может показать неправильный COST. У меня на практике несколько раз было что запрос с огромным COST намного быстрей работал, чем с маленьким COST.
А приминимо ли это к разным версиям оракла, и собсивенно оптимизатлра в нем? Вроде как алгоритм в 11 и 19 отличается на порядок.
как статистику не собирай, а explain plan не знает, что там по факту в байндах же будет :)
А как ориентироваться?
в основном своей головой, человеческий мозг все равно пока круче даже ораклового оптимизатора :)
подсунуть реальные значения и дать сделать bind peeking
у нас на OLTP базах у большинства клиентов bind peeking отключен нафиг :)
exactly. Запросы надо писать так, чтобы у oracle не было шансов выбрать план отличный от того, что задумал писатель запроса :)
без хинтов не всегда возможно :(
это да, особенно с табличками, которые 99% временно пустые
Смотреть параметры оптимизатора, что там наменяли... Вообще мне нравится фраза "неправильный кост" - что значит неправильный? 😂
Обсуждают сегодня