查詢在Azure中執行緩慢的瓶頸

Question

我有標準層中的Azure SQL數據庫，10個DTU。

我該如何「預測」CPU密集查詢的性能（因爲這似乎是緩慢的原因）？

爲了說明問題，將使用perf_test表，可以填充像這樣（腳本可以被提高了很多，但在這裏不是一個點）：

CREATE TABLE dbo.perf_Test 
(
    PolicyDescriptionID INT IDENTITY PRIMARY KEY, 
    col1 NVARCHAR(100), 
    col2 NVARCHAR(100), 
    col3 NVARCHAR(100), 
    col4 NVARCHAR(100), 
    col5 NVARCHAR(100), 
) 

GO 
SET NOCOUNT ON; 

DECLARE @i INT = 0 
WHILE @i < 100000 
BEGIN 
    DECLARE @NumberI int = CAST(RAND() * 100000 AS INT); 
    DECLARE @NumberC VARCHAR(6); 
    SET @NumberC = 
     CASE 
      WHEN @NumberI < 10 THEN '00000' + CAST(@NumberI AS VARCHAR(6)) 
      WHEN @NumberI < 100 THEN '0000' + CAST(@NumberI AS VARCHAR(6)) 
      WHEN @NumberI < 1000 THEN '000' + CAST(@NumberI AS VARCHAR(6)) 
      WHEN @NumberI < 10000 THEN '00' + CAST(@NumberI AS VARCHAR(6)) 
      WHEN @NumberI < 100000 THEN '0' + CAST(@NumberI AS VARCHAR(6)) 
      ELSE CAST(@NumberI AS VARCHAR(6)) 
     END; 

    INSERT INTO dbo.perf_Test(col1, col2, col3, col4, col5) 
      VALUES(
       @NumberC, -- char 
       @NumberC + RIGHT(@NumberC, 3) + @NumberC, -- casts as nvarchar 
       @NumberC + 'adslk3ājdsfšadjfads', 
       @NumberC, 
       @NumberC 
       ); 
    SET @i = @i + 1; 
END 

對於許多查詢天青將執行相同作爲本地機器。但對於醜陋查詢它執行更糟糕：

SELECT * 
FROM dbo.perf_Test 
WHERE 
     col1 LIKE '%263a%' 
    OR col2 LIKE '%263a%' 
    OR col3 LIKE '%263a%' 
    OR col4 LIKE '%263a%' 
    OR col5 LIKE '%263a%' 

天青： 掃描計數1，邏輯讀取1932年（休息0） SQL Server的執行時間：CPU時間= 16毫秒，經過時間= 6718毫秒

OnPrem： 掃描計數1，邏輯讀取1932年 SQL Server的執行時間：CPU時間= 563毫秒，經過時間= 482毫秒。

邏輯讀是一樣的「壞」的例子，但這個查詢執行在蔚藍的大致相同：

SELECT * 
FROM dbo.perf_Test 
WHERE col2 = '038743743038743' 

天青： 掃描計數1，邏輯讀取1932年 SQL Server的執行時間： CPU時間= 32毫秒，經過時間= 22毫秒。

OnPrem： 掃描計數1，邏輯讀取1932 SQL Server執行時間：CPU時間= 16毫秒，經過時間= 7毫秒。

返回行是〜100 rows-相同 '壞' 的例子，但此查詢執行在天青

SELECT * 
FROM dbo.perf_Test 
WHERE col1 like N'0975%' 

天青大致相同： 掃描計數1，邏輯讀取1932 SQL服務器執行時間：CPU時間= 16毫秒，經過時間= 26毫秒。

OnPrem： 掃描計數1，邏輯讀取1932 SQL Server執行時間：CPU時間= 15毫秒，耗用時間= 35毫秒。

如果我把一些CPU密集型查詢，差別又是巨大的（2和35秒天藍）：

SELECT SUM(CAST(t1.col1 AS BIGINT) + CAST(t2.col1 AS BIGINT)), COUNT(t2.col1) 
FROM dbo.perf_Test t1 
    CROSS JOIN dbo.perf_Test t2 
WHERE t1.col3 LIKE '%263a%' 
OPTION (MAXDOP 1) 

Answer 1

如果我把一些CPU密集型查詢，差別又是巨大的（2 VS在蔚藍35秒）：

這是因爲一個查詢可以被節流，直到資源可用，你是比較SQLAZURE（標準級10 DTU你onprem），這是不準確的比較

下圖顯示了一些粗糙的讀取和寫入的服務層

你可以假設，標準層的測量將大大減少，並在資源不可用於查詢，它會等待。

有一些好處使用Azure的像透明的補丁，備份，高庫存情況時，總是在你使用enterprise..so有一些權衡你必須做出當你去到雲

下面是步驟，我會爲了試試下面的查詢

1.Run，​​看看是否有任何DTU度量的是一貫> 90％一段時間，如果是的話，我會升級到下一個服務層

select top 1 with ties end_time,B.DTUpcnt,b.DTUMetric 
from sys.dm_db_resource_stats t 
cross apply 
(values 
    (avg_cpu_percent,'avg_cpu_percent'), 
    (avg_data_io_percent,'avg_data_io_percent'), 
    (avg_memory_usage_percent,'avg_memory_usage_percent'), 
    (avg_log_write_percent,'avg_log_write_percent') 
    )b(DTUPcnt,DTUMetric) 
    order by row_number() over (partition by end_time order by DTUMetric desc) 

2.I也會嘗試微調使用的查詢g更多的DTU或提供更多的計算能力

來預測具有交叉連接的查詢的性能，您將需要確保這些表處於緩衝區，所以不會有IO將會減少CPU使用率。

你也可以嘗試在蔚藍inmemory OLTP表爲它們