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

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

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

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

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

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

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

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

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

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

Четвертый тип проблемы наиболее тонкий. На диаграмме запроса, по меньшей мере, с одной большой таблицей есть несколько фильтров со средней степенью

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

Решения сложных проблем

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

Когда очень быстро - это еще недостаточно быстро

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