Что за экзекуционный план?
Смотри, самое простое. У тебя есть две таблицы в JOIN, например, большая и маленькая. В принципе этот запрос можно выполнить двумя способами: либо циклом по первой таблице, либо циклом по второй. При этом время выполнения может отличаться существенно. Если делать цикл по большой таблице, то мы читаем данные (допустим с диска) последовательно, маленькая в памяти, и нам надо прочитать данные один раз. Если делать цикл по маленькой, то данные из большой читаются рандомно (то одна запись, то другая) и это плохо по причине того, что диск буферизирует чтения, данные у нас постоянно гоняются с диска в память, больше операций, ... Поэтому, оптимизатор должнен выбрать порядок, в котором будут браться таблицы, которые участвуют в JOIN.
Далее условия. Поскольку размер таблицы важен, но если у нас есть WHERE, то мы можем использовать индекс, и тут вопрос, а сколько реально там будет данных. Оптимизатор использует статистику, например, если у нас есть 200 стран и стоит WHERE COUNTRY = 'UKRAINE' и мы знаем, что у нас миллион записей, то оптимизатор может прикинуть, что тут должно получиться примерно 1000000 / 200 = 5000.
Далее, на практике может оказаться, что а нас в базе 99% украинцев. И тут надо как-то порешать этот вопрос с тем, чтобы оптимизатор не лоханулся. Например, можно попросить вести гистограмму значений для таблицы. И тогда оптимизатор будет точнее оценивать сколько будет записей в том или ином подзапросе. Но надо тратить время на саму статистику.
Далее, построение плана выполнения запроса достаточно дорогостоящая операция, которая требует перебора вариантов, обращения к разной статистике, и т. п. Поскольку у нас часто не много вариантов SQL запросов, то часто проще посчитать хеш запроса, и если он у нас уже есть, то использовать уже вычисленный план. Что приводит к тому, что параметры лучше передавать как параметры, а не вставлять напрямую в текст запроса, потому что в этом случае хеши будут разные.
Если сделать параметром WHERE COUNTRY=:COUNTRY_NAME: то... тут уже и гистограмма не работает, ибо всё равно план надо составлять когда значение параметра неизвестно. Ну точнее гистограмма работает, она может сказать, что в плохом случае будет 990 000, в хорошем нуль. И тут или сервер должен вести статистику выполнения запросов и смотреть какая вероятность значения того или иного параметра. Или программист для случая України может написать отдельный запрос, не используя параметр, чтобы они по разному выглядели для оптимизатора.
Ну ещё иногда есть коментарии — хинты оптимизатору, которые позволяют задать порядок таблиц, сделать условие более приоритетным, ...