Чем может помочь эта книга 25

Чем может помочь эта книга

Настройка SQL состоит из трех основных этапов. Необходимо:

1) понять, какой план выполнения (путь к данным, запрашиваемым вашим SQL-оператором) у вас имеется;

2) изменить SQL или базу данных, чтобы получить выбранный план выполнения;

3) выбрать оптимальный план выполнения.

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

Вот достаточно хорошо работающая аналогия. Понимание первого этапа дает вам чистое ветровое стекло; вы видите, где находитесь. Понимание второго шага вкладывает вам в руки рулевое колесо; вы можете изменять направление движения. Понимание третьего шага дает вам карту с отметкой вашего текущего положения, а также того места, куда вы хотите попасть. Представьте себе, что вы находитесь в чужом городе без дорожных знаков, без карты и пытаетесь как можно быстрее найти отель, название которого не знаете. Представили? Теперь вы начинаете постигать задачу обучения настройке SQL Без систематического использования третьего этапа проблема настройки SQL оказывается даже хуже, чем наша задача заблудившегося водителя. Обладая достаточным запасом времени, путешественник может исследовать всю двухмерную сетку городских улиц, но состоящая из 20 предложений операция соединения (JOIN) содержит около 20! (20 факториал, или 1 X 2 X 3 X 4 X ... X 19 X 20) возможных планов выполнения, то есть необходимо исследовать 2 432 902 008 176 640 ООО возможных вариантов. Даже ваш компьютер не сможет перебрать все комбинации в данном пространстве поиска. Для настройки вам необходим метод, которым вы можете воспользоваться вручную.

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

1. Какой план выполнения является наилучшим и как это узнать, не прибегая к полному перебору всех вариантов?

2. Чем отличается текущий план выполнения от идеального плана выполнения, если он от него вообще отличается?

3. Если различие между фактическим и идеальным планами выполнения имеет значение, то как можно изменить определенную комбинацию SQL-запросов

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

4. Предоставляет ли новый план выполнения необходимый уровень производительности SQL-запросов?

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

Если посмотреть на проблему настройки SQL с этой новой точки зрения, то мы получим неожиданное преимущество. Единственная действительно значительная часть проблемы - решение, какой план выполнения является наилучшим - практически не зависит от нашего выбора реляционной базы данных. Наилучший план выполнения всегда остается наилучшим планом выполнения, будем ли мы выполнять оператор в Oracle, Microsoft SQL Server или DB2, поэтому знание этого факта намного полезнее, чем все, что мы узнаем об особенностях базы данных определенного поставщика. (Я даже смею утверждать, что наилучший план выполнения, вероятнее всего, не сильно изменится в планируемых в ближайшем будущем версиях этих баз данных.)

Бонус

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

ПРИМЕЧАНИЕ-

Я часто заменяю понятие запрос понятием SQL-onepamop. Большинство проблем настройки относится к запросам (например, запросом является оператор SELECT). Что же касается прочего, проблема обычно заключается в подзапросе, вложенном в задачу обновления или вставки.

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

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

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

OD 4т

О 0.3

1 41

С 0.0002 ОТ

Рис. 1.1. Пример диаграммы запроса ПРИМЕЧАНИЕ -

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

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

Внешние решения

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