Сортировка И соединение

в диаграмме отсутствуют любые указания на сортировку (ORDER BY), группировку (GROUP BY) и фгшьтрацию после группировки (HAVING). Эти операции практически никогда не имеют большого значения для производительности запроса. Шаг сортировки, который они обычно включают, может влиять на скорость выполнения, но для изменения его стоимости мало что можно сделать, и эта стоимость обычно не так велика по сравнению с производительностью плохо выполняющегося запроса.

Имена таблиц

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

Подробные условия соединения

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

Абсолютные размеры таблиц

(в противоположность относительным)

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

ПРИМЕЧАНИЕ

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

Подробности условий фильтрации

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

Когда диаграммы запросов помогают лучше всего

Так же, как некоторые проблемы эквивалентности слишком просты, чтобы требовать абстракции (например: У Джонни было пять яблок, он съел два, сколько яблок осталось? ), некоторые запросы, подобные запросу в примере 5.L, настолько просты, что абстрактное и формальное представление проблемы может и не потребоваться. Если бы все запросы были двусторонними соединениями, вы бы прекрасно справлялись без диаграмм запросов. Но в реальных приложениях соединения шести и больше таблиц, и даже соединения 20 и более таблиц встречаются не настолько редко, как вы могли бы предположить. Особенно часто подобные многосторонние соединения встречаются среди запросов, которые вам все же придется настраивать, так как эти более сложные запросы с большей вероятностью требуют ручной настройки. (Мой персональный рекорд - 115-стороннее соединение, а настройка соединений более чем 40 таблиц - обыкновенная рутинная работа.) Чем более полно нормализована ваша база данных и чем сложнее пользовательский интерфейс, тем вероятнее, что вам придется работать с многосторонними соединениями. Это миф, что современные базы данных не могут обрабатывать 20-сторонние соединения. Хотя это правда, что базы данных (некоторые в большей степени, чем другие) с гораздо большей вероятностью требуют ручной настройки для получения пристойной производительности таких сложных запросов, чем для простых.

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

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

Абстрактная демонстрация использования диаграмм запросов

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

ПРИМЕЧАНИЕ -

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

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

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