Полезные привычки при написании операторов T-SQL (часть 3)

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

Изображение 1 хороших привычек при написании операторов T-SQL (часть 3)

Часть 1
Изображение 2 хороших привычек при написании операторов T-SQL (часть 3)

Часть 2

Изучите схемы кеширования

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

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

С появлением SQL Server 2005 Microsoft предоставляет DMV (динамические представления управления), которые позволяют просматривать сохраненные диаграммы. Используя DMV, вы можете многое узнать о диаграммах кеширования. Вот краткий список вещей, которые вы можете идентифицировать:

  1. Текст относится к диаграмме кеша

  2. Количество выполняемых раз кэширования кеша
  3. Размер кэшированной диаграммы

<

p style=»text-align: justify;»>В следующей части статьи я покажу вам, как использовать DMV для изучения информации кеша.

Создайте несколько диаграмм для заметок или лишних пробелов

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

Ниже приведен пример двух разных операторов T-SQL:

ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product
ИДТИ
ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product — вернуть записи
ИДТИ

Как видите, у меня одинаковые два оператора T-SQL. Оба возвращают все записи из таблицы AdventureWorks.Production.Product. Как вы думаете, сколько карт кеша создаст SQL-сервер при выполнении приведенного выше кода? Чтобы ответить на этот вопрос, я изучу информацию о диаграммах кэша, используя DMV в SQL Server 2005 и SQL Server 2008. Чтобы увидеть диаграммы, созданные двумя указанными выше операторами T-SQL, я запущу следующий код:

DBCC FREEPROCCACHE
ИДТИ
ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product
ИДТИ
ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product — вернуть записи
ИДТИ
ВЫБЕРИТЕ stats.execution_count как exec_count,
p.size_in_bytes как [size],
[sql]. [text] в виде [plan_text]
ИЗ sys.dm_exec_cached_plans p
внешнее применение sys.dm_exec_sql_text (p.plan_handle) sql
присоединиться к sys.dm_exec_query_stats stats ON stats.plan_handle = p.plan_handle
ИДТИ

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

exec_count размер plan_text
———- —— ———
1 40960 SELECT * FROM AdventureWorks.Production.Product — возврат записей
1 40960 ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product

Как видите, два оператора SELECT создают две разные схемы кэширования, и каждая из них выполняется (число exec_count). Причина, по которой это происходит, заключается в том, что два оператора SELECT не совсем одинаковы. Второй оператор SELECT немного отличается, потому что есть дополнительные примечания. Также обратите внимание на размер диаграммы: 40960 байт — размер памяти слишком велик для очень простого оператора T-SQL. Следовательно, вы должны быть осторожны при добавлении примечаний к коду, чтобы сервер не создавал более избыточных диаграмм.

Еще одна причина создания нескольких диаграмм кеширования для одних и тех же операторов T-SQL — это пробелы. Следующие два утверждения идентичны, за исключением пробелов:

ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product
ИДТИ
ВЫБРАТЬ * ИЗ AdventureWorks.Production.Product
ИДТИ

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

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

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

Увеличьте производительность и уменьшите объем памяти

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

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован.