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

 

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

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

Тоу Д. Настройка SQL. Для профессионалов — СПб.: Питер, 2004. — 333 c.
ISBN 5-94723-959-0
Скачать (прямая ссылка): nastroykasqldlyaprof2004.djvu
Предыдущая << 1 .. 129 130 131 132 133 134 < 135 > 136 137 138 139 140 141 .. 161 >> Следующая


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

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

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

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

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

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

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

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

275

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

проблем

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

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

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

277

¦ Кэшируйте в памяти все, что однажды может потребоваться повторяющемуся запросу, и затем по необходимости извлекайте данные из кэша приложения.
Предыдущая << 1 .. 129 130 131 132 133 134 < 135 > 136 137 138 139 140 141 .. 161 >> Следующая
Реклама
Авторские права © 2009 AdsNet. Все права защищены.
Rambler's Top100