Информационный сайт

 

Реклама
bulletinsite.net -> Книги на сайте -> Программисту -> Тоу Д. -> "Настройка SQL. Для профессионалов" -> 12

Настройка SQL. Для профессионалов - Тоу Д.

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 6 7 8 9 10 11 < 12 > 13 14 15 16 17 18 .. 161 >> Следующая


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

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

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

1. Введение

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

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

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

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

Бонус

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

ПРИМЕЧАНИЕ--------------------------------------------------------------------

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

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

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

27

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

OD

S P О 0.3 ODT

А С 0.0002 ОТ

Рис. 1.1. Пример диаграммы запроса

ПРИМЕЧАНИЕ --------------------------------------------------------------------------------

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

Иногда решение проблемы производительности требует решения логической задачи. Даже если проблемы не зависят друг от друга (и вы можете улучшить производительность, не исправляя логические ошибки), вам может понадобиться выполнить множество дополнительных действий, находя эти ошибки и убеждаясь, что они исправлены. В этой книге такие логические ошибки рассматриваются обстоятельно, включая подробные описания, объясняющие, как найти каждую из подобных ошибок и что с ними делать. При выполнении упражнений на диаграммы SQLfl даже рекомендую вам взять любую сложную написанную вручную SQL-программу — просто чтобы найти эти незаметные логические ошибки, пусть даже вы знаете, что программа прекрасно работает. В зависимости от используемого инструмента некоторые продукты, автоматически генерирующие SQL-код, обычно позволяют избегать большинства логических проблем.
Предыдущая << 1 .. 6 7 8 9 10 11 < 12 > 13 14 15 16 17 18 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100