SQL Azureのクエリパフォーマンス - でも、チューンドクエリではひどく遅い

Question

ここでは、2つの非クラスタ化インデックスに依存している基本的なクエリです：

まったく同じデータベースは、事実上すべてのハードウェア上で、SQL Server 2008でホストされている

SELECT cc.categoryid, count(*) from company c 
INNER JOIN companycategory cc on cc.companyid = c.id 
WHERE c.placeid like 'ca_%' 
GROUP BY cc.categoryid order by count(*) desc 

これは< 500ミリ秒を返します。キャッシュバッファをクリアしても、これは従来のSQLでは約1秒で返されます。

Azureでは、毎回返されるまでに約3.5秒かかります。そこ

一部articlesは、人々がSQL Azureのでのクエリのパフォーマンスと、一般的に満足していることを示唆しているように見えます。しかし、ここでは、「明白な」チューニングが疲れていて、話すべきネットワーク待ち時間の問題がないという基本的なシナリオがあります。大きいテーブル（companycategroyは1.2Mレコードを持っています、場所は7.5Kを持っています）で働いているときはただは本当にです。

合計データベースサイズは4GBを超えません。 「Web」エディションと「Enterprise」エディションを選択しても、大きな違いはありません。

私には何が欠けていますか？

これは基本的な例に過ぎず、より洗練されたクエリでは悪化し、すべてがreviewedであり、チューニングされ、オンプレミスで十分に機能します。ここで

は、実行計画です：

|--Sort(ORDER BY:([Expr1004] DESC)) 
     |--Compute Scalar(DEFINE:([Expr1004]=CONVERT_IMPLICIT(int,[Expr1007],0))) 
      |--Hash Match(Aggregate, HASH:([cc].[CategoryId]), RESIDUAL:([XX].[dbo].[CompanyCategory].[CategoryId] as [cc].[CategoryId] = [XX].[dbo].[CompanyCategory].[CategoryId] as [cc].[CategoryId]) DEFINE:([Expr1007]=COUNT(*))) 
       |--Hash Match(Inner Join, HASH:([c].[Id])=([cc].[CompanyId])) 
         |--Index Scan(OBJECT:([XX].[dbo].[Company].[IX_Company_PlaceId] AS [c]), WHERE:([XX].[dbo].[Company].[PlaceId] as [c].[PlaceId] like N'ca_%')) 
         |--Index Scan(OBJECT:([XX].[dbo].[CompanyCategory].[IX_CompanyCategory_CompanyId] AS [cc])) 

そしてここでは、統計情報は以下のとおりです。次のように

SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 
SQL Server parse and compile time: 
    CPU time = 14 ms, elapsed time = 14 ms. 

(789 row(s) affected) 

Table 'Worktable'. Scan count 0, logical reads 0, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'CompanyCategory'. Scan count 1, logical reads 5183, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 
Table 'Company'. Scan count 1, logical reads 8710, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0. 

(1 row(s) affected) 

SQL Server Execution Times: 
    CPU time = 3328 ms, elapsed time = 3299 ms. 
SQL Server parse and compile time: 
    CPU time = 0 ms, elapsed time = 0 ms. 

SQL Server Execution Times: 
    CPU time = 0 ms, elapsed time = 0 ms. 

インデックスの定義は以下のとおりです。

CREATE NONCLUSTERED INDEX [IX_Company_PlaceId] ON [dbo].[Company] 
(
    [PlaceId] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

CREATE NONCLUSTERED INDEX [IX_CompanyCategory_CompanyId] ON [dbo].[CompanyCategory] 
(
    [CompanyId] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

ALTER TABLE [dbo].[Company] ADD CONSTRAINT [PK_Company_Id] PRIMARY KEY CLUSTERED 
(
    [Id] ASC 
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) 
GO 

Answer 1

彼らはあなたのマシン上のクエリは、おそらく（クエリで使用されるすべての操作が並列ん）並列化しながら、クエリの1つのCPUコアを使用するように見えます。

ただし、索引検索は何らかの理由でLIKE述語に使用されますが、索引検索で十分です。

c.placeid >= 'ca' 
AND c.placeid < 'cb' 

をし、それがIX_CompanyPlaceIdにIndex Seekに計画を変更した場合に参照してください。

LIKEの代わりにこの明示的な条件を使用してみてください。

Answer 2

ただ、いくつかのこと：

• Azureに最新の統計情報がありますか？ 1.2Mの行テーブルのハッシュマッチに少し気をつけています
• Azureは自動統計を持っていますか？ない場合は、ローカル・データベースは、SQL Azureのが
• はなぜc.placeid文字列であることの統計のいくつかのために、最適なクエリプラン
• インデックスc.placeidを選択するために使用することができないことをより多くの情報を持っているのでしょうか？これはcompanyidとc.idに続いていますか？私はこれがハッシュマッチを持っている理由だと思っています。代わりに整数サロゲートキーに加わってみてください。

Answer 3

インデックスのメンテナンスにはまだ手助けが必要なので、このリンクをAzure SQLデータベースのインデックス管理に掲載しています。私たちは、インデックスのメンテナンスを行うために、異なる弾性プールの私たちの350+データベース間で実行するためにランブックを使用し

https://blogs.msdn.microsoft.com/azuresqldbsupport/2016/07/03/how-to-maintain-azure-sql-indexes-and-statistics/

。私たちが行ったように、他の人が役に立つ情報を見つけてくれることを望みます。