Настройка приложений и баз данных для повышения производительности в Базе данных SQL Azure

Применимо к: База данных SQL Azureбазе данных SQL в Fabric

После выявления проблемы с производительностью, с которой вы столкнулись с базой данных База данных SQL Azure или Fabric SQL, эта статья поможет вам:

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

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

Настройка приложения

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

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

Лучшие практики и антипаттерны в разработке приложений для Azure SQL Database

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

• Приложения с низкой производительностью из-за "частых взаимодействий".

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

• Базы данных с интенсивной рабочей нагрузкой, которые не могут работать на одном компьютере.

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

• Приложения с неоптимальными запросами

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

• Приложения с неоптимальной схемой доступа к данным

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

  Сведения о том, как предотвратить повторную блокировку в базе данных SQL Azure, см. в статье Анализ и предотвращение взаимоблокировок в базе данных SQL Azure и базе данных SQL Fabric.

Настройка базы данных

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

Выявление и добавление отсутствующих индексов

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

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

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
    WHILE @a < 20000
    BEGIN
        INSERT INTO dbo.missingindex(col2) VALUES (@a);
        SET @a += 1;
    END
    COMMIT TRANSACTION;
    GO
SELECT m1.col1
    FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1)
    WHERE m1.col2 = 4;

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

Этот запрос можно использовать для оценки потенциально отсутствующих индексов:

SELECT
   CONVERT (varchar, getdate(), 126) AS runtime
   , mig.index_group_handle
   , mid.index_handle
   , CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact *
        (migs.user_seeks + migs.user_scans)) AS improvement_measure
   , 'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' +
        CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + '
        (' + ISNULL (mid.equality_columns,'')
        + CASE WHEN mid.equality_columns IS NOT NULL
        AND mid.inequality_columns IS NOT NULL
        THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '') + ')'
        + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement
   , migs.*
   , mid.database_id
   , mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
   INNER JOIN sys.dm_db_missing_index_group_stats AS migs
      ON migs.group_handle = mig.index_group_handle
   INNER JOIN sys.dm_db_missing_index_details AS mid
      ON mig.index_handle = mid.index_handle
 ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

В этом примере запрос привел к этому предложению.

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])  

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

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

Дополнительные сведения о настройке индексов с помощью запросов отсутствующих индексов см. в статье Настройка некластеризованных индексов с предложениями отсутствующих индексов.

Настройка и оптимизация запросов с помощью подсказок

Оптимизатор запросов в Базе данных SQL Azure напоминает традиционный оптимизатор запросов SQL Server. Большинство лучших практик по настройке запросов и пониманию ограничений модели обоснования для оптимизатора запросов также применимы к Azure SQL Database. Настроив запросы в Базе данных SQL Azure, можно снизить общие требования к ресурсам. Ваше приложение может работать с более низкими затратами, чем его ненастроенный аналог, поскольку оно может использовать меньший объем вычислительных ресурсов.

Примером является то, как оптимизатор запросов вносит параметры "на лету". Это распространено в SQL Server и также применяется к Базе данных SQL Azure. Во время компиляции оптимизатор запросов вычисляет текущее значение параметра с целью создания более оптимального плана запроса. Хотя эта стратегия часто может привести к плану запросов, который значительно быстрее, чем план, скомпилированный без известных значений параметров, в настоящее время он работает несовершенно как в Azure SQL Database. (Новая функция интеллектуальной производительности запросов, представленная в SQL Server 2022 с именем Оптимизация плана чувствительности к параметрам, устраняет сценарий, в котором один кэшированный план для параметризованного запроса не является оптимальным для всех возможных входящих значений параметров. В настоящее время Оптимизация плана чувствительности к параметрам недоступна в базе данных SQL Azure.)

Ядро СУБД поддерживает подсказки запросов (директивы), чтобы можно было более осознанно указать намерение и переопределить стандартное поведение для анализа параметров. Вы можете использовать подсказки, если поведение по умолчанию несовершенно для определенной рабочей нагрузки.

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

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
   WHILE @a < 20000
   BEGIN
     INSERT INTO psptest1(col2) values (1);
     INSERT INTO psptest1(col2) values (@a);
     SET @a += 1;
   END
   COMMIT TRANSACTION
   CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1
      WHERE col2 = @param1
      ORDER BY col2;
    END
    GO

CREATE PROCEDURE psp2 (@param2 int)
   AS
   BEGIN
      INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
      ORDER BY col2
      OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
   END
   GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

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

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
   BEGIN
      EXEC psp1 @param1=2;
      TRUNCATE TABLE t1;
      SET @i += 1;
    END

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

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
    WHILE @i < 1000
    BEGIN
        EXEC psp2 @param2=2;
        TRUNCATE TABLE t1;
        SET @i += 1;
    END

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

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

При запуске теста с параметром SET STATISTICS IO установленным на ON, логическое сканирование в этом примере выполняется в фоновом режиме. Вы можете увидеть, что план выполнил 1148 операций чтения (что является неэффективным, если обычно нужно вернуть только одну строку).

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

В системном представлении sys.resource_stats можно увидеть эффект, характерный для База данных SQL Azure. Существует задержка с момента выполнения теста и при заполнении таблицы данными. В этом примере первая часть выполнялась в рамках временного окна 22:25:00, а вторая часть — в 22:35:00. В более раннем временном окне использовано больше ресурсов, чем в позднем окне (из-за улучшений в эффективности плана).

SELECT TOP 1000 *
FROM sys.resource_stats
WHERE database_name = 'resource1'
ORDER BY start_time DESC

Вы можете проверить sys.resource_stats , использует ли ресурс для теста больше или меньше ресурсов, чем другой тест. При сравнении данных разделите время тестов, чтобы они не были в одном 5-минутном окне в представлении sys.resource_stats . Цель расчетов — минимизировать общее использование ресурсов, а не пиковую нагрузку. Обычно оптимизация части кода с целью уменьшения задержки выполнения также приводит к сокращению использования ресурсов. Убедитесь, что изменения, которые вы вносите в приложение, необходимы и что они не оказывают негативное влияние на пользовательский опыт для тех, кто может использовать указания запроса в приложении.

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

Оптимизация подключения и пула подключений

Чтобы сократить затраты на создание частых подключений к приложениям в базе данных SQL Azure, пул подключений доступен в поставщиках данных. Пул подключений включен в ADO.NET по умолчанию, например. Пул подключений позволяет приложению повторно использовать подключения и свести к минимуму затраты на установку новых.

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

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

  • пул подключений ADO.NET
  • пул подключений ODBC
  • пул подключений JDBC
  • Пул подключений PHP

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

• Механизмы проверки подлинности на основе маркеров, такие как проверка подлинности идентификатора Microsoft Entra, должны создавать новые маркеры после истечения срока действия. Физические подключения в пулах с истекшими токенами должны быть закрыты, а новые физические подключения должны быть созданы. Чтобы оптимизировать время, необходимое для создания физических подключений, использующих проверку подлинности на основе токенов:

  • Реализовать упреждающее, асинхронное продление токена: Первому подключению Open() для получения нового токена Entra ID может потребоваться небольшая задержка. Для многих приложений эта задержка не является незначительной и не требуется перенастройки. Если вы решите, чтобы ваше приложение управляло токенами, получите новые токены доступа до истечения срока их действия и убедитесь, что они сохранены в кэше. Это может свести к минимуму задержку получения токена во время создания физического подключения. Проактивное обновление маркера перемещает короткую задержку в процесс, не связанный с пользователем.
  • Настроить время существования маркеров:настройте политики истечения срока действия маркеров в Microsoft Entra ID так, чтобы они были как минимум равны ожидаемому времени существования логических подключений в вашем приложении. Хотя это и не обязательно, изменение срока действия токена позволяет сбалансировать безопасность и накладные расходы на повторное создание физических подключений.

• Отслеживать производительность подключения и использование ресурсов базы данных SQL Azure для выявления узких мест, таких как чрезмерное бездействие или недостаточно ограничений пула, а также соответствующим образом настраивать конфигурации. Используйте журналы идентификаторов Microsoft Entra для отслеживания ошибок истечения срока действия маркеров и обеспечения корректной настройки времени существования маркеров. Рекомендуется использовать Database Watcher или Azure Monitor, где это применимо.

Рекомендации по архитектуре очень больших баз данных в База данных SQL Azure

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

В следующих двух разделах рассматриваются два варианта решения проблем с очень большими базами данных в База данных SQL Azure, если не удается использовать уровень служб гипермасштабирования.

Шардинг между базами данных

Так как База данных SQL Azure выполняется на стандартном оборудовании, ограничения емкости для отдельной базы данных будут ниже, чем в традиционной локальной среде SQL Server. Некоторые клиенты используют техники шардирования, чтобы распределить операции по нескольким базам данных, когда их выполнение выходит за пределы возможностей отдельной базы данных в Azure SQL Database. Большинство клиентов, использующих сегментирование в Базе данных SQL Azure, разбивают данные одного измерения на несколько баз данных. При использовании этого подхода необходимо понимать, что часто приложения OLTP выполняют транзакции, которые применимы только к одной строке или небольшой группе строк внутри одной схемы.

Например, если в базе данных есть имя клиента, заказ и сведения о заказе (например, в AdventureWorks базе данных), эти данные можно разделить на несколько баз данных, группируя клиента с соответствующими заказами и сведениями о заказах. Это гарантирует, что данные клиента останутся в пределах отдельной базы данных. Приложение должно разбивать заказчиков по разным базам данных и эффективно распределять нагрузку. С сегментированием клиенты не только могут избежать максимального ограничения размера базы данных, но и База данных SQL Azure также могут обрабатывать рабочие нагрузки, которые значительно больше ограничений различных размеров вычислительных ресурсов, если каждая отдельная база данных вписывается в ограничения уровня обслуживания.

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

Функциональное секционирование

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

Если в Базе данных SQL Azure используется масштабируемая архитектура, лучше распределить функции приложения по разным базам данных. При использовании этого метода каждое приложение масштабируется независимо. По мере повышения нагрузки на приложение (и нагрузки на базу данных) администратор сможет определить объемы вычислительных ресурсов отдельно для каждой функции одного приложения. На пределе возможностей такая архитектура позволяет приложению быть больше, чем может обработать один обычный компьютер, благодаря распределению нагрузки по разным машинам.

Пакетные запросы

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

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

Кэширование на уровне приложения

Некоторые приложения баз данных имеют сильную нагрузку на чтение. Уровни кэширования могут снизить нагрузку на базу данных, а вслед за ней и объем вычислительных ресурсов, необходимый для поддержки базы данных с помощью Базы данных SQL Azure. С помощью Azure Cache для Redis, если у вас имеется нагрузка с интенсивным чтением, вы можете считать данные один раз (или, возможно, единожды на каждую машину уровня приложения в зависимости от конфигурации), а затем хранить эти данные за пределами вашей базы данных. Это способ уменьшения нагрузки базы данных (ЦП и операций ввода-вывода), но существует влияние на согласованность транзакций, так как данные, считываемые из кэша, могут быть не синхронизированы с данными в базе данных. Для многих приложений определенный уровень несогласованности приемлем, однако это подходит не для всех рабочих нагрузок. Мы советуем внимательно изучить требования к приложению, прежде чем использовать стратегию кэширования на уровне приложения.

Получите советы по настройке и проектированию

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

Чтобы узнать больше о сценарии и о том, как приступить к работе с ним, посетите эту страницу вики-сайта с советами по Azure SQL.

Чтобы узнать о новейших функциях и обновлениях в Azure SQL Database, см. Что нового в Azure SQL Database?

Связанный контент

• Мониторинг базы данных SQL Azure
• аналитика производительности запросов для базы данных SQL Azure
• мониторинг производительности с помощью динамических представлений управления
• наблюдатель баз данных
• Диагностика и устранение неполадок с высоким уровнем ЦП в базе данных SQL Azure
• Настройте некластеризованные индексы с предложениями по отсутствующим индексам
• Видеоролик: Рекомендации по загрузке данных из Базы данных SQL Azure