Книга: Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Планы и оптимизатор запросов Firebird

Планы и оптимизатор запросов Firebird

Для выполнения оператора SELECT или условия поиска сервер Firebird преобразует оператор в набор внутренних алгоритмов, называемых оптимизированным запросом. Каждый раз, когда оператор подготавливается для выполнения, оптимизатор вычисляет план поиска.

План запроса создает некий вид дорожной карты, которая сообщает серверу наименее дорогостоящую дорогу для требуемого процесса поиска, сортировки и поиска соответствия запрашиваемому результату. Чем более эффективный план сконструирует оптимизатор, тем быстрее оператор начнет возвращать результаты.

План создается в соответствии с наличием доступных индексов, с тем способом, каким индексы или потоки соединяются или сливаются, а также с методом поиска (методом доступа).

При вычислении плана оптимизатор будет просматривать каждый доступный индекс, выбирая или отвергая индексы в соответствии с их стоимостью. Помимо существования индекса он принимает во внимание другие факты, такие как размер таблицы, степень распределения различных значений в индексе. Если оптимизатор может определить, что использование индекса будет требовать больше издержек, чем последовательный просмотр строки за строкой в потоке, он может принять решение проигнорировать индекс, в пользу последовательного формирования промежуточного потока или создания потока естественным образом.

Для элементов плана в SQL Firebird применяет такой же синтаксис, какой он использует для передачи серверу. Понимание сгенерированных оптимизатором планов может быть очень полезным как для предвидения, каким образом оптимизатор будет решать конкретную задачу, так и в качестве основы для написания пользовательских планов.

Шаблон синтаксиса для фразы PLAN:

<спецификация-запроса> PLAN <выражение-плана>

Этот синтаксис позволяет задавать одно отношение или соединение двух или более отношений за один раз. Могут быть использованы вложенные скобки для задания любых комбинаций соединений. Операции передают свои результаты в выражении слева направо.

В используемой здесь нотации круглые скобки и запятые являются элементами синтаксиса. Фигурные скобки, квадратные скобки и символ вертикальной черты не являются частью синтаксиса- как и в ранее описанном синтаксисе они указывают, соответственно, обязательные и необязательные фразы и взаимоисключающие варианты.

plan-expression := [join-type] (plan-item-list)

join-type := [JOIN] | [SORT] [MERGE]

plan-item-list := plan-item | plan-item, plan-item-list

plan-item := table-identifier access-type | plan_expression

table-identifier := { table-identifier | alias-name } [table-identifier]

access-type := { NATURAL | INDEX (index-list) | ORDER index-name }

index-list := index-name | index-name, index-list

Тип соединения (join-type) может быть JOIN или MERGE.

* Тип соединения по умолчанию JOIN (т. е. соединение двух потоков с использованием индекса правого потока для поиска соответствующих ключей в левом потоке).

* MERGE выбирается, если нет используемых индексов. В этом случае два потока сохраняются в соответствующем порядке, а затем сливаются. В пользовательских планах скорость поиска будет увеличена при задании такого типа соединения, когда нет доступных индексов.

Идентификатор таблицы (table-identifier) задает поток. Он должен быть именем таблицы базы данных или алиасом. Если одна и та же таблица будет использована более одного раза, для нее должен быть указан алиас для каждого использования. Алиас должен следовать после имени таблицы при ее первом упоминании. Для спецификации базовых таблиц в просмотре синтаксис предоставляет возможность давать таблицам множество идентификаторов. Планы для просмотров обсуждаются в главе 24.

Тип доступа (access-type) должен быть одним из следующих:

* NATURAL - доступ к строкам осуществляется последовательно, без какого-либо особого порядка. Это тип доступа по умолчанию, он может быть опущен, тем не менее разумно включить его в пользовательский план для документирования;

* INDEX - позволяет указать один или более индексов для вычисления предикатов и проверки условий соединения в запросе;

* ORDER- указывает, что результат запроса должен быть отсортирован (упорядочен) по самому левому потоку с использованием индекса.

Элемент плана (plan-item) включает в себя план доступа, а также идентификатор таблицы или ее алиас.

Если вы не очень хорошо знакомы с планами запросов, вы, вероятно, будете удивлены, как весь этот синтаксис может транслироваться в план. Чуть позже синтаксис станет более осмысленным, когда мы посмотрим на некоторые планы, сгенерированные оптимизатором. Тем не менее в настоящий момент будет полезным посмотреть, как оптимизатор использует "материал" для его операций: соединения и условия поиска, требуемые в операторе, потоки, лежащие в основе спецификации запроса, и доступные индексы.

Цель оптимизатора - создать отражающий стратегию план, который, в соответствии с некоторыми факторами, скорее всего, начнет выдавать выходной поток наиболее быстрым образом. Вычисление плана может оказаться довольно неточным при использовании некоторых переменных, которые могут дать только приблизительную оценку. Рассматриваемые факторы включают:

* доступность индекса и селективность этого индекса. Фактор селективности, используемый в оценках, выбирается из системных таблиц при открытии базы данных. Даже в начале работы он может быть неверным, поскольку может изменяться в процессе операций обширных изменений, выполненных с момента последнего вычисления селективности;

* количество строк в таблицах потоков;

* существует ли критерий выбора, и если да, существует ли доступный или подходящий индекс;

* необходимость выполнения сортировок, как промежуточных (для слияния), так и окончательной (для упорядочения и группирования).

Применение термина "поток", который возникает при обсуждении оптимизатора, является просто общим способом наименования множества строк. Набор может содержать все строки и столбцы таблицы или это может быть подмножество данных таблицы, ограниченное некоторым образом спецификациями столбцов и условиями поиска. В процессе обработки запроса сервер может из существующего потока создавать новые потоки, такие как внутренний сортированный набор или набор значений подзапроса для сравнения IN(). См. также далее разд. "Реки".

Сервер Firebird может использовать в запросах индекс для трех видов задач.

* Сравнение: выполняется сравнение на условия равно, больше, меньше или STARTING WITH между значением столбца и константой. Если столбец индексирован, то индексный ключ используется для сокращения просматриваемых строк, делая ненужным сканирование всех строк таблицы данных.

* Соответствие потоков для соединений: если доступен индекс для столбцов, указанных в качестве условия соединения для потока с одной стороны соединения, то поток другой стороны будет отыскиваться первым, а его столбцы соединения будут проверяться на соответствие с помощью индекса.

* Сортировка и группирование: если условия в ORDER BY или GROUP BY указывают столбец, который индексирован, то этот индекс будет использован для поиска строк в нужном порядке, а операция сортировки не потребуется.

Когда критерий соединения использует индексированный столбец, сервер Firebird генерирует двоичный образ каждого выбранного потока. Затем, используя логику И/ИЛИ в соответствии с критерием поиска, индивидуальные потоки двоичных образов строк объединяются в единый двоичный образ, который описывает все подходящие строки. Если запросу нужно сканировать один и тот же поток за множество проходов, сканирование двоичного образа выполняется гораздо быстрее, чем повторный просмотр индексов.

В основе обработчика SQL Firebird лежит его родной язык двоичного представления (Binary Language Representation, BLR) и интерпретатор, состоящий из лексического анализатора, синтаксического анализатора, таблицы символов и генератора кода. Обработчик DSQL и включенные приложения передают BLR оптимизатору, и именно BLR, а не строки анализирует оптимизатор. Может случиться такое, что два разных оператора SQL интерпретируются в идентичные BLR.

! ! !

СОВЕТ. Если вам любопытно, на что похож BLR, вы можете использовать инструмент qli (в каталоге Firebird bin) для просмотра операторов. Запустите qli и выдайте команду SET BLR для включения отображения BLR. Документ по qli в формате PDF может быть загружен с различных сайтов Firebird, в том числе с http://www.ibphoenix.com.

Если у вас есть операторы SELECT в хранимой процедуре или триггере, вы можете просмотреть их в isql, выдав команду SET BLOB 2 и выбрав столбец

RDB$PROCEDURE BLR из таблицы RDB$PROCEDURES.

. ! .

Если не существует доступного индекса для условий соединения, оптимизатор задает сортированное слияние двух потоков. Сортированное слияние включает сортировку обоих потоков, а затем одновременное сканирование обоих потоков для их слияния в реку. Сортировка обоих потоков исключает необходимость постоянного сканирования правого потока для поиска соответствия ключам левого потока.

Рекой является поток, получающийся при слиянии двух потоков в результате соединения. Когда соединения являются вложенными, река может стать потоком для последующих операций. Различные стратегии слияния потоков в реки сравниваются по стоимости. Полученный в результате план использует лучшую стратегию, которую оптимизатор может определить для соединения пар потоков в порядке слева направо.

При вычислении стоимости стратегии соединения оптимизатор определяет весовые коэффициенты для порядка, в котором соединяются потоки. Альтернативные определения порядка больше подходят к внутренним соединениям, чем к внешним. Полные соединения требуют особой обработки.

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

При этом более важным, чем размер ветви соединения, является способ, каким читаются строки из правого потока. Тип доступа оценивается в соответствии с доступными индексами и их атрибутами (селективностью) в сравнении с естественным порядком и спецификациями сортировки, представленными в общей картине расчетов.

Если лучший индекс доступен для самого короткого потока, выбор самого большого потока в качестве управляющего потока может быть менее важным, чем экономия стоимости при выборе самого короткого потока с индексом высокой селективности (в идеале уникальный индекс). В этом случае подходящие строки в искомом потоке могут быть получены в результате одного прохода, а неподходящие строки игнорируются.

Многие графические инструменты администратора базы данных имеют средства для просмотра планов оптимизатора при подготовке оператора. Собственная утилита Firebird isql предоставляет две интерактивные команды для просмотра планов.

В интерактивной сессии isql вы можете использовать SET PLAN С необязательными ключевыми словами ON или OFF для переключения режима отображения плана в начале консольного вывода:

SQL>SET PLAN;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA SURNAME)

FIRST NAMES

SURNAME

George Stephanie

Abraham Allen

В другой команде переключателя вы можете для isql установить отображение некоторых статистических данных запроса в конце выводимых данных, которые могут оказаться очень полезными при тестировании альтернативных структур запроса и его планов:

SQL>SET STATS ON;

SQL> запускаете ваш запрос>

PLAN..

<вывод>

Current memory = 728316

Delta memory = 61928

Max memory = 773416

Elapsed time =0.17 sec

Buffers = 2048

Reads = 15

Writes = 0

Fetches = 539

Альтернативная команда переключателя SET PLANONLY [ON | OFF] подготавливает оператор и отображает план без выполнения запроса:

SQL>SET PLAN OFF;

SQL>SET PLANONLY ON;

SQL>SELECT FIRST_NAMES, SURNAME FROM PERSON

CON>ORDER BY SURNAME;

PLAN (PERSON ORDER XA_SURNAME)

Если вы собираетесь использовать план оптимизатора в качестве стартовой точки для конструирования пользовательского предложения PLAN, то имейте в виду, что синтаксис выводимого выражения идентичен требуемому синтаксису для выражения плана в операторе[80]. Неудобным является то, что в isql не существует возможности выводить план оптимизатора в текстовый файл.

! ! !

СОВЕТ. Графические инструменты, которые отображают планы, обычно предоставляют средства копирования/вставки.

. ! .

Следующие примеры используют запросы, которые вы сами можете проверить, используя тестовую базу данных employee.fdb, инсталлированную в ваш каталог примеров[81].

Этот запрос просто отыскивает все строки из таблицы соответствия в произвольном порядке. Хотя оптимизатор определяет наличие индекса (индекс первичного ключа), он его не использует для поиска:

SQL>SET PLANONLY ON;

SQL> SELECT * FROM COUNTRY;

PLAN (COUNTRY NATURAL)

Это все еще простой запрос без соединений:

SQL>SELECT * FROM COUNTRY ORDER BY COUNTRY;

PLAN (COUNTRY ORDER RDB$PRIMARYl)

Оптимизатор выбирает индекс первичного ключа, потому что он имеет запрашиваемое упорядочение; при этом не требуется создание промежуточного потока для сортировки.

Теперь давайте посмотрим, что произойдет, когда мы решим упорядочить тот же самый запрос по неиндексированному столбцу:

SELECT * FROM COUNTRY ORDER BY CURRENCY;

PLAN SORT ((COUNTRY NATURAL))

Оптимизатор выбирает выполнение сортировки, просматривая таблицу COUNTRY В естественном порядке.

Перекрестное соединение, которое обычно создает бесполезный набор, вовсе не использует критериев соединения:

SQL> SELECT Е.*, P.* FROM EMPLOYEE Е, PROJECT Р;

PLAN JOIN (Р NATURAL,Е NATURAL)

Оно просто сливает каждый поток в левой части с каждым потоком правой части. Оптимизатор не использует индексы. Однако этот пример полезен в качестве введения в соединение между алиасами двух таблиц в спецификации соединения и их использовании в плане.

Алиасы, указанные в запросе, используются в плане, выводимом оптимизатором. Для совместимости при создании пользовательского плана хорошей идеей является использование того же способа идентификации таблиц, как и в запросе. При этом, несмотря на то, что синтаксический анализатор не допускает смешивания идентификаторов таблиц и их алиасов в запросах, предложение PLAN допускает любое смешивание[82]. Например, следующий вариант является приемлемым. Обратите внимание, что оптимизатор допускает использование и идентификаторов таблиц в предложении PLAN.

SQL> SELECT Е.*, P.* FROM EMPLOYEE E, PROJECT P

CON> PLAN JOIN (PROJECT NATURAL, EMPLOYEE NATURAL);

PLAN JOIN (P NATURAL, E NATURAL)

Такое соединение денормализует отношение один-ко-многим - каждый служащий имеет одну или более записей истории заработной платы:

SELECT Е.*, S.OLD_SALARY, S.NEW_SALARY

FROM EMPLOYEE E

JOIN SALARY_HISTORY S

ON S.EMP_NO = E.EMP_NO;

PLAN JOIN (S NATURAL, E INDEX (RDB$PRIMARY7))

Оптимизатор выбирает цикл по (потенциально) самому длинному детальному потоку для поиска релевантных строк с использованием индекса уникального первичного ключа таблицы EMPLOYEE. В этом примере либо количество строк в каждой таблице будет приблизительно равным, либо количество строк в таблице SALARY_HISTORY не превысит количество строк в таблице EMPLOYEE в той мере, чтобы не достичь преимуществ уникального индекса в качестве ключа соответствия. Это внутреннее соединение, и оптимизатор разумно предполагает, что именно правый поток определит размер реки.

Давайте посмотрим, как оптимизатор трактует те же самые потоки, когда соединение является внешним левым:

SELECT Е. *, S.OLD_SALARY, S.NEW_SALARY

FROM EMPLOYEE E

LEFT JOIN SALARY_HISTORY S

ON S.EMP_NO = E.EMP_NO;

PLAN JOIN (E NATURAL, S INDEX (RDB$FOREIGN21))

В этот раз одна строка будет возвращена для каждой строки правого потока, независимо от того, будет ли существовать соответствующий ключ в управляющем потоке. Размер реки здесь не имеет значения, поскольку внешние соединения однозначно определяют, какая таблица должна быть в левой стороне, чтобы по ней проводить цикл просмотра. Это алгоритм внешнего соединения, который определяет метод доступа, не измеряющий потоки. С таблицей EMPLOYEE В левой части не существует возможности создать внешнее соединение путем просмотра таблицы SALARY_HISTORY с поиском в EMPLOYEE.

Поскольку оптимизатор не делает выбора относительно того порядка, в котором будут соединяться потоки, он просто выбирает наиболее подходящий индекс из SALARY_HISTORY.

В следующем примере размер таблицы не виден при использовании индекса уникального первичного ключа. Таблица DEPARTMENT содержит 21 строку, таблица PROJECT - 6 строк, и оптимизатор выбирает меньший индекс внешнего ключа для оптимизации поиска соответствия по большей таблице:

SELECT * FROM DEPARTMENT D

JOIN PROJECT P

ON D.MNGR_NO = P. TEAM_LEADER ;

PLAN JOIN (D NATURAL,P INDEX (RDB$FOREIGN13))

Использование индексированных спецификаций упорядочения может повлиять на то, как оптимизатор выбирает навигацию по потокам. Возьмем следующий пример:

SQL> SELECT P.*, E.FULL_NAME FROM PROJECT P JOIN EMPLOYEE E

ON E.EMP_NO = Р. TEAM_LEADER ORDER BY P.PROJ_NAME ;

PLAN JOIN (Р ORDER RDB$11, E INDEX (RDB$PRIMARY7))

Уникальный индекс для EMPLOYEE выбирается по причине неявного условия фильтра в критерии соединения. Запрос сокращает количество служащих, которые не являются руководителями, а уникальный индекс позволяет исключить сканирование таблицы EMPLOYEE. Выбор индекса фильтрации может также повлиять на необходимость использования навигационного индекса в PROJ_NAME для сортировки[83].

Оптимизатор выбирает индекс правой стороны, потому что правый поток будет того же размера, что и левый или (потенциально) большего размера. Опять же, оптимизатор не может сказать, что это отношение является отношением один к одному. Столбец PROJ_NAME, задающий порядок выходного набора, имеет уникальный индекс, созданный ограничением UNIQUE, чтобы использовать для сортировки, и оптимизатор выбирает этот индекс. Индекс сортировки появляется в плане первым, указывая серверу на необходимость сортировки левого потока перед тем, как он будет отыскивать соответствие ключа соединения в правом потоке.

Таблицы в следующем запросе являются неиндексированными копиями таблиц PROJECT и EMPLOYEE (см. сноску 4 ранее в этой главе):

SQL> SELECT PI.*, EL. FULL_NAME FROM PROJECT1 PI JOIN EMPLOYEEL EL ON EL.EMP_NO = PL.TEAM_LEADER ORDER BY PI. PROJ_NAME;

PLAN SORT (MERGE (SORT (EL NATURAL) , SORT (PI NATURAL)))

Потоки с обеих сторон будут сортироваться, а затем сливаться, полученная река снова будет сортироваться, потому что ни один из потоков не имеет требуемого порядка сортировки.

Рассмотрим тройное эквисоединение в следующем примере:

SQL> SELECT P.PROJ_NAME, D.DEPARTMENT, PDB. PROJECTED_BUDGET FROM PROJECT P

JOIN PROJ_DEPT_BODGET PDB ON P.PROJ_ID = PDB.PROJ_ID JOIN DEPARTMENT D ON PDB.DEPT_NO = D.DEPT_NO;

PLAN JOIN (D NATURAL, PDB INDEX (RDB$FOREIGN18), P INDEX (RDB$PRIMARY12))

Поскольку доступно множество подходящих индексов, оптимизатор выбирает метод доступа JOIN. Индекс, связывающий поток PDB с таблицей DEPARTMENT, будет использован для выбора потока DEPARTMENT. При обработке результирующей реки и потока PROJECT эквисоединение между первичным ключом таблицы PROJECT и большей по размеру (потенциально) реки дает возможность формировать реку с использованием индекса первичного ключа PROJECT для выборки данных из реки.

только с одним индексированным равенством

Для этого примера мы используем неиндексированные копии таблиц PROJECT и EMPLOYEE для демонстрации того, как оптимизатор будет использовать доступный индекс, когда он может применять лучший вариант условий неиндексированного эквисоединения:

SQL> SELECT PI.PROJ_NAME, DL.DEPARTMENT, PDB.PROJECTED_BUDGET FROM PROJECT1 PI

JOIN PROJ_DEPT_BUDGET PDB ON PI . PROJ_ID = PDB.PROJ_ID

JOIN DEPARTMENT1 Dl ON PDB. DEPT_NO = Dl. DEPT_NO;

PLAN MERGE (SORT

(PI NATURAL), SORT (JOIN (Dl NATURAL, PDB INDEX (RDB$FOREIGN18))))

В самом внутреннем цикле выбран индекс внешнего ключа для эквисоединения потока PDB и выбираемых подходящих строк потока DEPARTMENT. Заметьте, что выбор такого индекса ничего не выполняет с внешним ключом, для поддержки которого был создан индекс, поскольку таблица, на которую ссылается внешний ключ, даже не присутствует в операторе.

После этого результирующая река и поток PROJECT сортируются. В завершение (в самом внешнем цикле) два сортированных потока объединяются в один.

Когда в запросе задаются подзапросы и объединения, используется несколько операторов SELECT. Оптимизатор конструирует независимый план для каждого оператора SELECT. Возьмем следующий пример:

SELECT

P.PROJ_NAME,

(SELECT E.FULL_NAME FROM EMPLOYEE E

WHERE P.TEAM_LEADER = E.EMP_NO) AS LEADER_NAME

FROM PROJECT P

WHERE P.PRODUCT = 'software'

PLAN (Е INDEX (RDB$PRIMARY7) )

PLAN (Р INDEX (PRODTYPEX))

Первый план выбирает индекс первичного ключа таблицы EMPLOYEE для просмотра кодов TEAM_LEADER в первичной таблице подзапроса. Индекс PRODTYPEX для таблицы PROJECT используется для фильтрации строк в таблице PRODUCT, поскольку первым элементом ключа в этом индексе является столбец PRODUCT.

Интересно то, что если изменить тот же запрос, включив предложение упорядочения, то оптимизатор изменит свой выбор индекса для фильтрации и выберет уникальный индекс по PROJ_NAME для навигации по упорядочиваемому столбцу:

SELECT

P.PROJ_NAME,

(SELECT E.EULL_NAME FROM EMPLOYEE E

WHERE P.TEAM_LEADER = E.EMP_NO) AS LEADER_NAME

FROM PROJECT P

WHERE P.PRODUCT = 'software' ORDER BY 1;

PLAN (E INDEX (RDB$PRIMARY7))

PLAN (P ORDER RDB$11)

Синтаксис выражений, который использует оптимизатор для создания плана и передачи его серверу Firebird доступен в SQL в предложении PLAN. Это позволяет вам определять ваш собственный план, ограничивая оптимизатор в его выборе.

Предложение PLAN может быть задано почти в любом операторе SELECT, включая операторы, используемые в создании просмотров, в хранимых процедурах и подзапросах. Firebird версии 1.5 и выше также допускает предложения PLAN и в триггерах. Множество планов может быть указано независимо для запроса и любого подзапроса. При этом нет требования "все или ничего" - любое предложение плана является необязательным.

Предложение PLAN генерируется для оператора SELECT В хранимой процедуре выбора. Поскольку выходом хранимой процедуры выбора является виртуальный набор, любые условия будут основываться на доступе NATURAL. При этом любой оператор SELECT в хранимой процедуре будет оптимизирован, и для него можно применять пользовательский план.

! ! !

ПРИМЕЧАНИЕ. Конструирование пользовательского плана для оператора SELECT в просмотре создает собственные проблемы для разработчика. Более подробную информацию см. в разд. "Использование планов запросов для просмотров" главы 24.

. ! .

Вы должны задать имена и порядок использования для всех индексов, которые будут использованы.

Оптимизатор всегда создает план, даже если задан пользовательский план. Хотя оптимизатор не мешает созданному пользователем плану, он проверяет, какие индексы подходят для данного контекста. Альтернативные пути отбрасываются, но во всем остальном дела идут своим чередом. Таким образом, наличие пользовательского плана не отключает оптимизатор, и он все равно делает свою оценку и генерацию своего плана в тех аспектах, которые не были указаны в предложении PLAN.

Неверный индекс приведет к тому, что запрос не будет выполнен. Если любой предикат или условие соединения остаются после того, как все индексы, указанные в плане выражения, будут использованы, оптимизатор просто оценит потоки в соответствии с естественным порядком и порядком сортировки по умолчанию.

Представляя ваше собственное выражение плана, вы можете получить небольшое увеличение скорости за счет обхода работы оптимизатора. При этом разработка вашего собственного плана, основанная на структурных правилах управления вашими данными, может не дать ожидаемых вами удовлетворительных результатов, особенно если ваш план наследован от другой СУБД, которая использует структурные правила для оптимизации запросов.

Оптимизатор Firebird основан на стоимости (cost-based) и обычно создает лучший план, если ваша база данных хорошо поддерживается сервисными средствами. Поскольку геометрия индексов и данных может изменяться в процессе выполнения операторов - особенно, если изменяется или удаляется большое количество строк- никакой сгенерированный оптимизатором план не может оставаться статичным от одной подготовки запроса к другой. Если вы создаете статичное выражение PLAN, то ухудшение эффективности может стать результатом снижения производительности, что уберет все преимущества отмены работы оптимизатора.

Смысл сказанного здесь в том, что использование вашего собственного плана может оказаться палкой о двух концах. В процессе разработки вы можете чувствовать преимущество от использования плана, который, как вы верите, является лучшим, чем тот, который будет получен оптимизатором. В этом случае вы отключаете преимущества динамического оптимизатора, который может компенсировать последующие изменения в распределении данных или индексов.

Оглавление книги