Azure SQL Database でアプリケーションとデータベースのパフォーマンスを調整します

[アーティクル]
09/12/2024

Azure SQL Database で発生しているパフォーマンスの問題を特定できたら、この記事をお読みになって次の場合に役立ててください。

アプリケーションを調整し、パフォーマンスを向上させるベストプラクティスを適用します。
データをより効率的に処理するようにインデックスとクエリを変更して、データベースをチューニングします。

この記事では、該当する場合は、Azure SQL Database のデータベースアドバイザーの推奨事項と自動チューニングの推奨事項に従った作業を既に行っているものとします。また、監視とチューニングの概要に関する記事、「クエリストアを使用してパフォーマンスを監視する」、およびパフォーマンスの問題のトラブルシューティングに関連する関連記事を確認済みであることを前提としています。さらに、この記事では、コンピューティングサイズまたはサービスレベルを上げてデータベースに対するリソースを増やすことで解決できる CPU リソース使用率関連のパフォーマンスの問題がないことを前提としています。

注意

Azure SQL Managed Instance の同様のガイダンスについては、「Azure SQL Managed Instance でアプリケーションとデータベースのパフォーマンスを調整します」を参照してください。

アプリケーションの調整

従来のオンプレミス SQL Server では多くの場合、初回の容量計画のプロセスは、運用環境でアプリケーションを実行するプロセスから分離されます。最初にハードウェアと製品ライセンスが購入され、パフォーマンス調整は後で行われます。 Azure SQL を使用する場合、アプリケーションの実行と調整のプロセスを組み合わせることをお勧めします。オンデマンド容量の支払いモデルでは、現在必要とされる最小のリソースを使用するようにアプリケーションを調整できます。(不正確なことが多い) アプリケーションの将来的な成長計画の推測に基づいて、ハードウェアに過剰プロビジョニングを行うことはしません。

アプリケーションを調整しないでハードウェアリソースを過剰にプロビジョニングすることを選ぶユーザーもいます。この方法は、利用が集中する期間に重要なアプリケーションの変更を望まない場合に適していることがあります。しかし、アプリケーションを調整することで、リソース要件を最小限に抑え、毎月の請求額を抑えることができます。

Azure SQL Database のアプリケーション設計におけるベストプラクティスとアンチパターン

Azure SQL Database のサービスレベルは、アプリケーションのパフォーマンスの安定性と予測可能性を高めるように設計されています。一方で、いくつかのベストプラクティスを実践することで、コンピューティングサイズ内でリソースを最大限に活用するようアプリケーションを調整できます。多くのアプリケーションは、上位のコンピューティングサイズまたはサービスレベルに切り替えることでパフォーマンスが大幅に向上します。とはいえ、アプリケーションによっては、上位のサービスレベルの利点を活かすためにさらに調整が必要になります。次のような特性を備えたアプリケーションでは、パフォーマンスを向上させるためにアプリケーションに調整を加えることを検討してください。

"煩雑な" 動作が原因でパフォーマンスの低いアプリケーション

煩雑なアプリケーションでは、ネットワークの待機時間が重要なデータアクセス操作が過度に発生します。この種のアプリケーションでは、データベースに対するデータアクセス操作の数を減らすよう変更を施す必要があります。たとえば、アドホッククエリを一括処理したり、ストアドプロシージャにクエリを移動したりするなどの手法を使って、アプリケーションのパフォーマンスを向上させることができます。詳細については、「バッチクエリ」を参照してください。
単一のマシンではサポートし切れないほどワークロードが集中するデータベース

最高の Premium コンピューティングサイズのリソースを超えるデータベースでは、ワークロードのスケールアウトを活用できる場合があります。詳細については、「データベース間のシャーディング」と「機能的パーティション分割」を参照してください。
最適でないクエリを含むアプリケーション

クエリが十分に調整されていないアプリケーションの場合、上位のコンピューティングサイズの利点を活かせないことがあります。たとえば、WHERE 句がない、インデックスが足りない、統計が古いクエリです。これらのアプリケーションの場合、クエリパフォーマンスの標準的な調整方法で効果が得られます。詳細については、「インデックスの不足」と「クエリの調整とヒント」を参照してください。
データアクセス設計が最適ではないアプリケーション

デッドロックなど、データアクセスの同時性問題が内在するアプリケーションの場合、上位のコンピューティングサイズの利点を活かせないことがあります。 Azure キャッシュサービスや他のキャッシング技術を利用し、クライアント側でデータをキャッシュすることで、データベースに対するラウンドトリップを減らすことを検討してください。詳しくは、「アプリケーション層のキャッシュ」を参照してください。

Azure SQL Databaseでデッドロックが再発しないようにするには、「Azure SQL Databaseでデッドロックを分析して防止する」を参照してください。

データベースの調整

このセクションでは、データベースを調整するいくつかの手法について説明します。これらの手法を使用すると、アプリケーションから最良のパフォーマンスを引き出し、可能な限り下位のコンピューティングサイズでアプリケーションを実行することができます。これらの手法の一部は従来の SQL Server 調整のベストプラクティスと同じですが、その他のものは Azure SQL Database に固有です。場合によっては、データベースで使用されるリソースを調べ、さらに調整すべき領域を見つけることができるほか、従来の SQL Server 手法を拡大し、Azure SQL Database に応用することができます。

欠落したインデックスを特定して追加する

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;

インデックススキャンを特徴とする、少なくとも 1 つの

Azure SQL Database は、インデックス不足の一般的な状態を発見して修正するのに役立ちます。 Azure SQL Database に組み込まれている DMV には、クエリコンパイルが表示されます。クエリを実行するために見積もられたコストをインデックスで大幅に削減できる場合があります。クエリの実行中、データベースエンジンによって、各クエリプランが実行される頻度と、実行クエリプランとそのインデックスが存在した想定クエリプランの間で見積もられるギャップが追跡されます。これらの DMV を使用し、データベースとその実際のワークロードに関してワークロードコストを全体的に改善できる物理データベース設計の変更をすばやく推測できます。

次のクエリは、潜在的なインデックス不足の評価に使用できます。

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 容量は専用サーバーコンピューターの IO 容量より限られているということです。不必要な IO を最小限に抑え、サービスレベルの各コンピューティングサイズのリソース内でシステムを最大限に活用することが重要です。適切な物理データベース設計を選択すると、個々のクエリの待機時間のほか、スケールユニットごとに処理される同時要求のスループットを大幅に改善し、クエリを満たすために必要なコストを最小限に抑えることができます。

欠落インデックス要求を使用したインデックスのチューニングの詳細については、「欠落したインデックス提案を使用した非クラスター化インデックスのチューニング」を参照してください。

クエリの調整とヒント

Azure SQL Database のクエリオプティマイザーは、従来の SQL Server クエリオプティマイザーと似ています。クエリを調整し、クエリオプティマイザーの推論モデル制約を理解するためのベストプラクティスのほとんどは、Azure SQL Database にも活かすことができます。 Azure SQL Database のクエリを調整すると、総リソース要求を減らせる場合があります。下位のコンピューティングサイズで実行できるため、クエリが調整されていない場合に比べて少ないコストでアプリケーションを実行できます。

SQL Server でよく見られ Azure SQL Database にも適用される例は、クエリオプティマイザーによるパラメーターの "スニッフィング" です。コンパイル中、クエリオプティマイザーによってパラメーターの現在の値が評価され、より最適なクエリプランを生成できるかどうかが判断されます。この戦略を使用すると多くの場合、既知のパラメーター値を使用せずにコンパイルされたプランよりもはるかに高速なクエリプランが生成されます。ただし現時点では、Azure SQL Database の両方で動作が不完全です。 (SQL Server 2022 で導入された新しいインテリジェントなクエリパフォーマンス機能であるパラメーターに依存するプランの最適化は、パラメーター化されたクエリに対してキャッシュされた単一のプランが、受け取った可能性のあるすべてのパラメーター値に対して最適ではないというシナリオに対処します。現時点では、パラメーターに依存するプランの最適化は Azure SQL Database では使用できません)

意図をより慎重に指定し、パラメータースニッフィングの既定の動作をオーバーライドできるように、データベースエンジンはクエリヒント (ディレクティブ) をサポートしています。既定の動作が特定のワークロードに対して不完全である場合は、ヒントの使用を選択できます。

次の例は、パフォーマンスとリソースの両方の要件について最適でないプランがクエリプロセッサによって生成されるようすを示しています。この例から、クエリヒントを使用すると、データベースのクエリの実行時間とリソース要件を抑えることができることもわかります。

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 テーブル内に作成されます。最適なクエリプランは、選択されたパラメーターによって異なります。残念ながらプランキャッシング動作では、常に最も一般的なパラメーター値に基づいてクエリが再コンパイルされるとは限りません。そのため、平均すると別のプランの方がプランとしてより良い選択になる場合でも、最適でないプランがキャッシュされ、多くの値に使用される可能性があります。次に、(一方に特殊なクエリヒントが含まれていることを除いて) 同一の 2 つのストアドプロシージャがクエリプランによって作成されます。

-- 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

例のパート 2 を開始する前に少なくとも 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

この例の各パートでは、(テストデータセットとして使用するのに十分な負荷を生成するために) パラメーター化された挿入ステートメントが 1,000 回試行されます。ストアドプロシージャを実行するとき、クエリプロセッサは、その最初のコンパイル中にプロシージャに渡されるパラメーター値を調べます (パラメーターの "スニッフィング")。結果として生成されたプランがプロセッサによってキャッシュされ、パラメーター値が異なる場合でも、後の呼び出しで使用されます。最適なプランが使用されないことがあります。クエリが最初にコンパイルされたときのケースではなく、平均的なケースに対して最適なプランを選択するように、オプティマイザーを調整する必要がある場合があります。この例では、最初のプランは、パラメーターに一致する各値を見つけるためにすべての行を読み取る "スキャン" プランを生成します。

スキャンプランを使用したクエリチューニングを示すグラフィカル実行プランのスクリーンショット。

値 1 を使用してプロシージャを実行したため、結果として生成されたプランは値 1 に対して最適ですが、テーブルにある他のすべての値に対しては最適ではありません。各プランを無作為に選択した場合、結果は望んだものと異なることが予想されます。これは、プランの実行が遅く、より多くのリソースが使用されるためです。

SET STATISTICS IO を ON に設定してテストを実行すると、この例の論理スキャン作業がバックグラウンドで行われます。このプランによって 1,148 件の読み取りが行われたことがわかります (平均的なケースで返される行がたった 1 つの場合、非効率的です)。

論理スキャンを使用したクエリチューニングを示すグラフィカル実行プランのスクリーンショット。

例の 2 つ目の部分では、クエリヒントを利用し、コンパイルプロセス中に特定の値を使用するようにオプティマイザーに伝えます。この場合、パラメーターとして渡される値を無視し、UNKNOWN を想定するようにクエリプロセッサに強制します。これはテーブル内での頻度が平均的な値を示します (傾斜を無視)。結果として生成されるプランはシークベースのプランです。このプランはこの例のパート 1 のプランより全体的に高速であり、このプランで使用されるリソースもパート 1 のプランより全体的に少なくなっています。

クエリヒントを使用した後のクエリチューニングの結果を示すグラフィカル実行プランのスクリーンショット。

影響は、Azure SQL Database に固有の sys.resource_stats システムビューで確認できます。テストを実行してから、データがテーブルに入力されるまでに遅延が発生します。この例では、パート 1 は 22:25:00 の時間枠で実行され、パート 2 は 22:35:00 の時間枠で実行されています。遅い方の時間枠と比べ、早い方の時間枠でその時間枠のリソースがより多く使用されます (プランの効率性改善が理由)。

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

インデックスを改善した後のavg_cpu_percentの違いを示すsys.resource_statsテーブルのスクリーンショット。

注意

この例では規模を意図的に小さくしてありますが、最適でないパラメーターの影響は特に大規模なデータベースで顕著になります。極端なケースでは、速い場合は数秒単位、遅い場合は数時間単位の差異になります。

sys.resource_stats を調べると、あるテストで使用されるリソースが別のテストより多いか少ないか判断できます。データを比較するとき、sys.resource_stats ビューで同じ 5 分の枠に入らないようにテストのタイミングを離します。この演習の目標は、使用されるリソースの総量を最小限に抑えることであり、ピークリソースを最小限に抑えることではありません。一般的に、待ち時間のコードの一部を最適化すると、リソースの消費量も減ります。アプリケーションに施す変更が必要なものであることと、アプリケーションでクエリヒントを使用している他のユーザーのカスタマーエクスペリエンスに対し変更による悪影響がないことを確認してください。

ワークロードに一連の反復的なクエリが含まれる場合は、データベースをホストするために必要な最小リソースサイズ単位を把握できるため、たいてい、プラン選択肢の最適性を理解して検証することは合理的です。検証した後、プランのパフォーマンスが低くなっていないことを確認するために、ときどきプランを調べ直してください。詳細については、「クエリヒント (Transact-SQL)」をご覧ください。

Azure SQL Database における非常に大規模なデータベースアーキテクチャのベストプラクティス

Azure SQL Database で単一データベース向けに Hyperscale サービスレベルがリリースされる前は、ユーザーは個々のデータベースの容量制限に直面することがありました。 Hyperscale Elastic Pool ではストレージ上限は大幅に改善していますが、他のサービスレベルの Elastic Pool およびプールされたデータベースは、Hyperscale 以外のサービスレベルのストレージ容量制限によって引き続き制限される場合があります。

次の 2 つのセクションでは、Hyperscale サービスレベルを使用できない場合に、Azure SQL Database で非常に大規模なデータベースに発生する問題を解決するための 2 つのオプションについて説明します。

注意

エラスティックプールは、Azure SQL Managed Instance、オンプレミスの SQL Server インスタンス、Azure VM 上の SQL Server、Azure Synapse Analytics では使用できません。

データベース間のシャーディング

Azure SQL Database は汎用ハードウェアで実行されるため、従来のオンプレミス SQL Server インストールと比べ、1 つのデータベースに対する容量制限が低くなります。データベース操作が Azure SQL Database の 1 つのデータベースの制限内に収まらないときにシャーディング手法を使用して、複数のデータベースに操作を分散しているユーザーもいます。 Azure SQL Database でシャーディング手法を利用するほとんどのユーザーは、1 つのディメンションのデータを複数のデータベースで分割します。この手法では、OLTP アプリケーションは多くの場合、スキーマ内の 1 行のみ、またはほんの数行から成るグループに適用されるトランザクションを実行することを理解しておく必要があります。

注意

Azure SQL Database にシャーディングを支援するライブラリが追加されました。詳細については、「エラスティックデータベースクライアントライブラリの概要」をご覧ください。

たとえば、(AdventureWorks データベースのように) あるデータベースに顧客名、注文、および注文詳細が含まれている場合、関連する注文と注文詳細の情報を使って顧客をグループ化することで、このデータを複数のデータベースに分割できます。顧客のデータは 1 つのデータベース内にとどめておくことができます。アプリケーションはデータベース間で顧客を分割し、効果的に負荷を分散します。シャーディングを使用すると、顧客はデータベースサイズの最大制限を回避できるだけでなく、個々のデータベースがそのサービスレベルの制限内に収まる限り、各コンピューティングサイズの制限を大幅に超えるワークロードを Azure SQL Database で処理できます。

データベースシャーディングではソリューションの総リソース容量を減らすことはできませんが、複数のデータベースにまたがる非常に大規模なソリューションに対応する際に非常に効果的です。各データベースを異なるコンピューティングサイズで実行し、リソース要件の高い、非常に大規模で "効果的な" データベースに対応できます。

機能的パーティション分割

ユーザーは多くの場合、1 つのデータベースのさまざまな機能を組み合わせます。たとえば、店舗の在庫を管理するロジックがアプリケーションに含まれている場合、そのデータベースには、在庫に関連付けられているロジック、購買発注の追跡、ストアドプロシージャ、月末報告を管理するインデックス付きビュー/マテリアライズドビューが含まれていることがあります。この手法では、バックアップなどの操作に関するデータベースの管理が容易になりますが、アプリケーションの機能全体でピーク負荷を処理できるようにハードウェアのサイズを調整する必要もあります。

Azure SQL Database 内でスケールアウトアーキテクチャを使用する場合、アプリケーションの異なる機能を異なるデータベースに分割することをお勧めします。この手法を使用すると、各アプリケーションは独立してスケーリングされます。管理者は、アプリケーションがビジー状態になった (データベースの負荷が増えた) ときに、アプリケーションの機能ごとにコンピューティングサイズを個別に選択できます。制限はありますが、このアーキテクチャを使用して、1 台の汎用コンピューターで処理できる範囲を超えてアプリケーションの規模を大きくできます。これは、複数のコンピューター間で負荷が分散されるためです。

バッチクエリ

大量のアドホッククエリを頻繁に実行してデータにアクセスするアプリケーションの場合、アプリケーション層とデータベース層の間で行われるネットワーク通信の応答に、相当な時間が費やされます。アプリケーションとデータベースが両方同じデータセンターに存在する場合でも、データアクセス操作の数が多ければ、この 2 つの間のネットワーク待機時間は長くなる可能性があります。データアクセス操作のネットワークラウンドトリップを減らすために、アドホッククエリを一括処理すること、またはストアドプロシージャとしてそれらをコンパイルすることを検討してください。アドホッククエリを一括処理すると、複数のクエリを 1 つの大きなバッチとして 1 回のトリップでデータベースに送信できます。アドホッククエリをストアドプロシージャにコンパイルすると、それらを一括処理した場合と同じ結果が得られます。ストアドプロシージャを使用すると、クエリプランがデータベースにキャッシュされる機会が増えるという利点もあるため、ストアドプロシージャを再度使用できます。

一部のアプリケーションでは、書き込みが集中します。場合によっては、書き込みを一括処理する方法を検討することで、データベースの IO 総負荷を減らすことができます。これは多くの場合、ストアドプロシージャとアドホックバッチ内で自動コミットトランザクションではなく明示的なトランザクションを使用するのと同じくらい単純です。使用できるさまざまな手法の評価については、 Azure でのデータベースアプリケーションのバッチ処理手法に関するページをご覧ください。独自のワークロードで実験を行って、一括処理に適したモデルを見つけてください。モデルによってはトランザクションの整合性の保証がわずかに異なる場合があることを理解しておいてください。リソース使用を最小限に抑える適切なワークロードを見つけるには、整合性とパフォーマンスの適度なバランスを見つける必要があります。

アプリケーション層のキャッシュ

一部のデータベースアプリケーションでは、ワークロードの大半が読み取りになります。キャッシュ層を利用すれば、データベースの負荷を減らすことができます。また、Azure SQL Database を使用してデータベースをサポートするために必要なコンピューティングサイズを下げられる可能性があります。 Azure Cache for Redis を利用すると、読み取りが多いワークロードがある場合に、データを 1 回 (または、構成方法に応じてアプリケーション層コンピューターごとに 1 回) 読み込んでから、データベースの外部にそのデータを格納することができます。この方法は、データベースの負荷 (CPU と読み取り IO) を減らすことができるものの、トランザクションの整合性に影響があります。データがキャッシュから読み込まれると、データベースのデータとの同期が失われることがあるためです。多くのアプリケーションではある程度の不整合が許容されますが、すべてのワークロードで許容されるとは限りません。アプリケーション層のキャッシュ手法を実装する前に、あらゆるアプリケーション要件を完全に理解しておく必要があります。

構成とデザインのヒントを取得する

Azure SQL Database を使用する場合は、Azure SQL Database でデータベースの構成と設計を改善するためのオープンソースの T-SQL スクリプトを実行できます。このスクリプトを使用すると、オンデマンドでデータベースが分析され、データベースのパフォーマンスと正常性を向上させるためのヒントが提供されます。ベストプラクティスに基づいて構成と運用上の変更を提案するヒントもありますが、データベースエンジンの高度な機能を有効にするなど、ワークロードに適したデザインの変更を推奨するヒントもあります。

スクリプトの詳細について、および作業を開始するには、Azure SQL ヒントの Wiki ページを参照してください。

Azure SQL データベースの最新の機能と更新プログラムを最新の状態に保つには、「AAzure SQL データベースの最新情報」を参照してください。

DTU ベースの購入モデルについて学習する
仮想コアベースの購入モデルについて学習する
Azure エラスティックプールの概要を読む。
エラスティックプールを検討すべき状況を見つける。
動的管理ビューを使用してパフォーマンスを監視するを読む
Azure SQL Database での高い CPU の診断とトラブルシューティングについて学習する。
インデックスの候補が見つからない、クラスター化されていないインデックスを調整する
ビデオ: Azure SQL Database でのデータ読み込みのベストプラクティス
Azure Monitor を使用して Azure SQL データベースを監視する

次の方法で共有

Azure SQL Database でアプリケーションとデータベースのパフォーマンスを調整します

アプリケーションの調整

Azure SQL Database のアプリケーション設計におけるベストプラクティスとアンチパターン

データベースの調整

欠落したインデックスを特定して追加する

クエリの調整とヒント

Azure SQL Database における非常に大規模なデータベースアーキテクチャのベストプラクティス

データベース間のシャーディング

機能的パーティション分割

バッチクエリ

アプリケーション層のキャッシュ

構成とデザインのヒントを取得する

フィードバック

その他のリソース

次の方法で共有

Azure SQL Database でアプリケーションとデータベースのパフォーマンスを調整します

アプリケーションの調整

Azure SQL Database のアプリケーション設計におけるベスト プラクティスとアンチパターン

データベースの調整

欠落したインデックスを特定して追加する

クエリの調整とヒント

Azure SQL Database における非常に大規模なデータベース アーキテクチャのベスト プラクティス

データベース間のシャーディング

機能的パーティション分割

バッチ クエリ

アプリケーション層のキャッシュ

構成とデザインのヒントを取得する

関連するコンテンツ

フィードバック

その他のリソース

Azure SQL Database のアプリケーション設計におけるベストプラクティスとアンチパターン

Azure SQL Database における非常に大規模なデータベースアーキテクチャのベストプラクティス

バッチクエリ