Изменение SQL-кода для получения хорошего плана 319

I - Index SeekC...(... [Products]. [Product PKey] (wrapped line) AS [P]). SEEK:([P].[Product ID] - [OD].[Product ID]) ORDERED)

(19 row(s) affected)

Хорошие новости! С исправленным SQL-кодом вы получаете оптимальный план. Просто из любопытства можно проверить план выполнения для исходного SQL-кода и получить тот же самый результат! Очевидно, SQL Server выполняет преобразование данных для константы, не запрещая использование индекса.

Изменение базы данных для получения лучшего плана

Предыдущие результаты в DB2 и SQL Server уже продемонстрировали, что в дизайне базы данных есть все необходимые индексы, чтобы использовать желаемый план вьшолнения. Но в Oracle могут отсутствовать индексы, которые существуют в других базах данных. Таким образом, вы можете пропустить этот шаг. Однако если бы вы еще не знали, что индексы существуют, то проверили бы, есть ли индексы по Customers(Phone Number), Orders(Customer ID) и Order Details(Order ID), используя методы, описанные в главе 3. Обычно можно принять как должное, что необходимые индексы по первичным ключам уже существуют. Проверяйте отсутствующие индексы по первичному ключу, только когда наиболее вероятная причина неправильного плана вьшолнения не объясняет проблему и заставляет проверить, нет ли каких-нибудь иных источников проблем.

Изменение SQL-кода для получения хорошего плана

Можно предположить, что хороший план в Oracle можно получить после исправления несовместимости типов на этой платформе. Как-никак, другие базы данных сумели избежать преобразования типа индексированного столбца и выдали хороший план. Поэтому стоит испытать новый план в Oracle, но с исправленным сравнением С. Phone Number = 6505551212, чтобы избежать неявного преобразования типов данных. Используйте исходные настройки для синтаксической оптимизации, чтобы проверить план выполнения: PLAN

SELECT STATEMENT SORT ORDER BY NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS NESTED LOOPS TABLE ACCESS BY INDEX ROWID 4*CUST0MERS INDEX RANGE SCAN CUSTOMER PHONE NUMBER TABLE ACCESS BY INDEX ROWID 1*0RDERS

INDEX RANGE SCAN ORDER CUSTOMER ID TABLE ACCESS BY INDEX ROWID 2*0RDErIdETAILS INDEX RANGE SCAN ORDER DETAIL ORDER ID TABLE ACCESS BY INDEX RDWID 5*SHIPMENTS INDEX UNIQUE SCAN SHIPMENT PKEY TABLE ACCESS BY INDEX RDWID 3*PR0DUCTS INDEX UNIQUE SCAN PRODUCT PKEY TABLE ACCESS BY INDEX ROWID 6*ADDRESSES INDEX UNIQUE SCAN ADDRESS PKEY

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

Теперь оба оптимизатора Oracle возвращают оптимальный план - значит, работа закончена! Чтобы убедиться в этом, можно выполнить SQL-запрос со значением параметра sql plus равным timing on. Оказывается, Oracle возвращает результат всего за 40 миллисекунд, по сравнению с предыдущим показателем производительности 2,4 секунды для исходного синтаксического плана вьшолнения и 8,7 секунды для исходного стоимостного плана вьшолнения.

Изменение приложения

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

Взгляд в будущее

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

ПРИМЕЧАНИЕ-

Однако когда вам нужны методы для особых случаев, это значит, что они вам действительно нужны!

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

Взгляд в будущее 321

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