SQL Azure에서 쿼리 실행이 훨씬 느린 이유는 무엇입니까?

SQL Azure에서 쿼리 실행이 훨씬 느린 이유는 무엇입니까?

Azure에 평가판 계정을 만들고 데이터베이스를 배포했습니다.SmarterAsp.

에서 할 때SmarterAsp\MyDatabase결과는 2초 안에 나타났습니다.

그나동쿼실에서 경우Azure\MyDatabase94초가 걸렸습니다.

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.195초

Smarterasp.net - 경과 시간 = 2.449초

LocalServer - 경과 시간 = 1.716초

Azure에 대한 제 평가판 계정과 관련하여 위와 같은 저장 프로시저를 실행할 때 스마트보다 빠른 속도를 낼 수 있는지 확인하는 것을 주요 목표로 만들었습니다.데이터베이스 서비스 계층 - 기본, 성능 수준 - 기본(5DTU) 및 최대 크기 2GB를 선택합니다.

내 데이터베이스에는 16개의 테이블이 있고, 1개의 테이블에는 145284개의 행이 있으며, 데이터베이스 크기는 11MB입니다.이것은 제 앱을 위한 테스트 데이터베이스입니다.

제 질문은 다음과 같습니다.

1. 이 쿼리(sp)를 최적화하려면 어떻게 해야 합니까?
2. Azure는 소규모 데이터베이스(100mb-1Gb)에 권장됩니까?성능 대 비용!

귀하의 의견을 토대로 한 결론:

• 나는 쿼리에 대해 제안된 변경을 가했고 50% 이상으로 성능이 향상되었습니다 - 감사합니다 리머스
• Azure S2에서 쿼리를 테스트했는데 업데이트된 쿼리의 경과 시간이 11초였습니다.

• P1에서 쿼리를 다시 테스트했더니 경과 시간이 0.5초였습니다 :)

• 스마트에 대한 동일한 업데이트된 쿼리ASP의 경과 시간은 0.8초였습니다.

이제 Azure의 계층이 무엇인지, 그리고 매우 좋은 쿼리를 갖는 것이 얼마나 중요한지 알게 되었습니다(Index가 무엇이고 그의 장점/단점도 이해했습니다).

모두 감사합니다, 루시안.

이것은 무엇보다도 성과의 문제입니다.당신은 코드가 제대로 작동하지 않는 문제를 처리하고 있으며 병목 현상을 파악하여 해결해야 합니다.저는 지금 나쁜 2초 퍼포먼스를 말하는 것입니다.SQL 서버 성능 분석 방법의 지침을 따르십시오.이 쿼리가 웹 앱에 대해 로컬로 허용되는 수준(5ms 미만)으로 실행되면 Azure SQL DB로 이식하는 질문을 할 수 있습니다. 현재 평가판 계정은 기존의 비효율성만 강조하고 있습니다.

업데이트 후

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

그래서 무엇입니까? 그것은.iddepartment종대치에 int 는또.nvarchar 왜 용사이를 사용합니까?(max)?

다음은 수행해야 할 작업입니다.

• @iddepartment in in inner dynamic SQL
• 만다두를 nvarchar(max)전환만들기iddepartment그리고.@iddertment match
• 에서 인덱스 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;

커버링 인덱스는 단연코 가장 중요한 해결책입니다.그것은 분명히 여기 있는 것보다 더 많은 정보를 필요로 합니다.모든 하위 장을 포함한 인덱스 설계를 읽습니다.

좀 더 일반적인 의견으로 말하자면, 이런 종류의 쿼리는 행 저장소보다 더 많이 저장합니다. 기본적으로 데이터 크기가 작다고 생각합니다.Azure SQL DB는 업데이트 가능한 클러스터된 열 저장소 인덱스를 지원하므로 심각한 데이터 크기를 예상하여 이 인덱스를 실험할 수 있습니다.로컬 박스에 엔터프라이즈/개발이 필요합니다.

(업데이트: 쿼리를 최적화하는 방법도 묻도록 원래 질문이 변경되었습니다. 이것도 좋은 질문입니다.원래의 질문은 왜 이 대답이 무엇에 관한 차이인지였습니다.

개별 쿼리의 성능은 성능 계층의 영향을 많이 받습니다.문서에는 계층이 로드에 관한 것이라는 의미가 포함되어 있지만, 이는 엄밀하게 사실이 아닙니다.

저는 S2 데이터베이스를 시작으로 당신의 테스트를 다시 실행하고 거기서 시작하겠습니다.

평가판 구독을 사용하는 것 자체가 성능에 영향을 미치지는 않지만 무료 계정을 사용하면 실제 사용할 수 없는 B 레벨을 사용할 수 있습니다. 로컬에서 실행하는 데 2초가 걸리는 쿼리는 사용할 수 없습니다.

예를 들어, S1과 S2 사이를 이동하더라도 개별 쿼리의 성능에 현저한 차이가 있습니다.실험을 수행하려면 "하루의 모든 부분"에 대해 하루 요금이 부과된다는 것을 기억하십시오. 이는 S 수준에서는 괜찮지만 P 수준을 테스트할 때는 주의해야 합니다.

작년에 Azure에서 새로운 계층을 도입했을 때 SQL의 호스팅 모델을 변경했습니다.이전에는 많은 데이터베이스가 공유 sqlserver.exe에서 실행되었습니다.새 모델에서 각 데이터베이스는 리소스 제약 샌드박스에서 실행되는 자체 sqlserver.exe를 효과적으로 가져옵니다.이것이 그들이 "DTU 사용"을 제어하는 방법이지만 일반적인 성능에도 영향을 미칩니다.

고객님의 계정이 평가판이라는 사실과는 무관합니다. 고객님이 선택한 성능 수준이 낮아졌기 때문입니다.

다른 서비스(SmarterAsp) 및 로컬 인스턴스를 실행하는 경우 크기 제한이 아닌 성능 제한이 없을 수 있습니다.

현재로서는 실제 DTU가 무엇을 의미하는지/DTU 번호의 종류가 로컬 컴퓨터 또는 다른 호스팅 공급자에 설치된 SQL 서버와 연결되어 있는지를 종합하는 것이 불가능합니다.

하지만 이와 관련해 일부 좋은 분석(https://cbailiss.wordpress.com/2014/09/16/performance-in-new-azure-sql-database-performance-tiers/) 이 이뤄졌지만 공식적인 내용은 없습니다.

언급URL : https://stackoverflow.com/questions/31086778/why-is-running-a-query-on-sql-azure-so-much-slower