web-dev-qa-db-ja.com

SQL Azureでクエリを実行するのに非常に遅いのはなぜですか？

Azure にトライアルアカウントを作成し、SmarterAspからデータベースを展開しました。

SmarterAsp\MyDatabaseでピボットクエリを実行すると、結果は2秒で表示されました。

ただし、Azure\MyDatabaseで同じクエリを実行すると、94秒かかりました。

SQL Server 2014 Management Studio（トライアル）を使用してサーバーに接続し、クエリを実行します。

私のアカウントは試用アカウントであるため、この速度の違いはありますか？

私の質問に関するいくつかの関連情報

クエリは次のとおりです。

ALTER procedure [dbo].[Pivot_Per_Day]
@iyear int,
@imonth int,
@iddepartment int

as

declare @columnName Nvarchar(max) = ''
declare @sql Nvarchar(max) =''

select @columnName += quotename(iDay) + ','
from (
        Select day(idate) as iDay
        from kpivalues where year(idate)=@iyear and month(idate)=@imonth
        group by idate
        )x

set @columnName=left(@columnName,len(@columnName)-1)

set @sql ='


Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay   

from kpi

inner join kpivalues on kpivalues.idkpi=kpi.idkpi

inner join kpitarget on kpitarget.idkpi=kpi.idkpi

inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi

where iddepartment='+convert(nvarchar(max),@iddepartment)+'

group by kpiname,target, ivalues,idate)x

pivot
(
     avg(ivalues)
    for iDay in (' + @columnName + ')
) p'

execute sp_executesql @sql

このクエリを3つの異なるサーバーで実行すると、ピボットテーブルが画面に表示されるまでの経過時間に関して、異なる結果が得られました。

Azure-経過時間= 100.165秒

Smarterasp.net-経過時間= 2.449秒

LocalServer-経過時間= 1.716秒

Azureでの試用アカウントについては、上記のようなストアドプロシージャを実行するときにSmarterよりも高速になるかどうかを確認することが主な目標でした。データベースサービス層-Basic、パフォーマンスレベル-Basic（5DTUs）、およびMaxを選択します。サイズ2GB。

私のデータベースには16個のテーブルがあり、1個のテーブルには145284行あり、データベースサイズは11MBです。私のアプリのテストデータベース。

私の質問は：

  1. このクエリ（sp）を最適化するにはどうすればよいですか？
  2. Azureは小規模なデータベース（100mb-1Gb）に推奨されますか？パフォーマンス対コストを意味します！

入力に基づく結論：

  • クエリに提案された変更を加え、パフォーマンスが50％以上改善されました-Remusありがとう
  • Azure S2でクエリをテストしましたが、更新されたクエリの経過時間は11秒でした。

  • P1でクエリを再度テストし、経過時間は0.5秒でした:)

  • smarterASPの同じ更新されたクエリの経過時間は0.8秒でした。

これで、Azureの層とは何か、非常に優れたクエリを持つことがいかに重要であるかが明確になりました（インデックスとは何か、彼の長所/短所も理解しました）

ありがとう、ルシアン

sqlazuressmsazure-sql-databasesql-server-2014
23
Lucian Bumb

これは何よりもまずパフォーマンスの問題です。あなたはあなたの側でパフォーマンスの悪いコードを扱っているので、ボトルネックを特定して対処しなければなりません。今、悪い2秒のパフォーマンスについて話しています。 SQL Serverパフォーマンスの分析方法 のガイドラインに従ってください。このクエリを取得して、Webアプリでローカルに受け入れられるように実行すると（5ミリ秒未満）、Azure SQL DBに移植する質問をすることができます。現在、トライアルアカウントは既存の非効率性のみを強調しています。

更新後

_...
@iddepartment int
...
iddepartment='+convert(nvarchar(max),@iddepartment)+'
...
_

それは何ですか？ iddepartment列はintまたはnvarcharですか？そして、なぜ_(max)_を使用するのですか？

これがあなたがすべきことです：

  • 内部動的SQLで_@iddepartment_をパラメーター化する
  • nvarchar(max)変換の実行を停止します。 iddepartmentおよび_@iddertment_タイプを一致させる
  • iddepartmentおよびすべてのidkpisのインデックスを確認する

内部SQLをパラメーター化する方法は次のとおりです。

_set @sql =N'
Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay   
from kpi
inner join kpivalues on kpivalues.idkpi=kpi.idkpi
inner join kpitarget on kpitarget.idkpi=kpi.idkpi
inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi
where iddepartment=@iddepartment
group by kpiname,target, ivalues,idate)x
pivot
(
     avg(ivalues)
    for iDay in (' +@columnName + N')
) p'

execute sp_executesql @sql, N'@iddepartment INT', @iddepartment;
_

カバリングインデックスは、断然、最も重要な修正です。これには明らかに、ここにあるよりも多くの情報が必要です。読み取り インデックスの設計 すべてのサブチャプターを含む。

より一般的なコメントとして：この種のクエリは columnstores rowstoreよりも適していますが、データサイズは基本的に小さいと考えています。 Azure SQL DBは、更新可能なクラスター化された列ストアインデックスをサポートします。深刻なデータサイズを見込んで試してみることができます。ローカルボックスでのエンタープライズ/開発が必要です。

13
Remus Rusanu

（更新：クエリを最適化する方法も尋ねるように元の質問が変更されました-これも良い質問です。元の質問はwhy the differenceこれがこの答えの目的です）。

個々のクエリのパフォーマンスは、パフォーマンス層の影響を大きく受けます。ドキュメンテーションは、層が負荷に関するものであることを暗示していますが、これは厳密には真実ではありません。

開始点としてS2データベースを使用してテストを再実行し、そこから進みます。

試用版サブスクリプションに参加すること自体がパフォーマンスに影響することはありませんが、無料アカウントでは、おそらく実際には何も使用できないBレベルを使用していることになります。ローカルで実行するのに2秒かかるクエリではありません。

たとえば、S1とS2の間を移動しても、個々のクエリのパフォーマンスに顕著な違いが見られます。実験したい場合は、「1日の任意の部分」に対して1日課金されることを覚えておいてください。これはおそらくSレベルでは問題ありませんが、Pレベルのテストには注意してください。

背景用; Azureが昨年新しい層を導入したとき、SQLのホスティングモデルを変更しました。以前は、多くのデータベースが共有sqlserver.exeで実行されていました。新しいモデルでは、各データベースは、リソースに制約のあるサンドボックスで実行される独自のsqlserver.exeを効果的に取得します。それが「DTUの使用」を制御する方法ですが、一般的なパフォーマンスにも影響します。

13
Frans

アカウントが試用版であることとは関係ありません。選択したパフォーマンスレベルが低いためです。

他のサービス（SmarterAsp）および実行中のローカルインスタンスでは、おそらくパフォーマンスの制限はなく、サイズの制限はありません。

この時点で、実際のDTUの意味/ローカルマシンまたは他のホスティングプロバイダーにインストールされているSqlサーバーに関連付けられているDTU番号の種類をまとめることはできません。

しかし、いくつかの良い分析があります（ https://cbailiss.wordpress.com/2014/09/16/performance-in-new-Azure-sql-database-performance-tiers/ ）これは公式ではありません。

2
Low Flying Pelican