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

对于许多查询，azure将执行与本地计算机相同的操作。但对于丑陋的查询，它的表现要差得多：

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 ms，已用时间= 6718 ms

OnPrem：扫描计数1，逻辑读取1932 SQL Server执行时间：CPU时间= 563 ms，已用时间= 482 ms 。

逻辑读取与“坏”示例相同，但此查询在azure中执行大致相同：

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

天青：扫描计数1，逻辑读取1932 SQL Server执行时间：CPU时间= 32毫秒，已用时间= 22毫秒。

OnPrem：扫描计数1，逻辑读取1932 SQL Server执行时间：CPU时间= 16毫秒，已用时间= 7毫秒。

返回的行是~100行 - 与“坏”示例相同，但此查询在天蓝色中执行大致相同

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

天青：扫描计数1，逻辑读取1932 SQL Server执行时间：CPU时间= 16毫秒，已用时间= 26毫秒。

OnPrem：扫描计数1，逻辑读取1932 SQL Server执行时间：CPU时间= 15毫秒，已用时间= 35毫秒。

如果我进行一些CPU密集型查询，差异很大（天蓝色2 vs 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对35秒）：

这是因为在资源可用之前可以限制查询，并且您正在将您的onprem与SQLAZURE（标准层10 DTU）进行比较，这不是准确的比较

下面的图表显示了服务层的一些粗略读写

您可以假设，标准层测量将会少得多，当资源不可用于查询时，它将等待。

使用Azure时有一些好处，例如透明修补，备份，高可用性，总是使用企业......因此，当你去云时，你必须做出一些权衡

以下是我将按顺序尝试的步骤

1.运行以下查询以查看任何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.我还会尝试微调使用更多DTU或提供更多计算能力的查询

使用交叉连接来预测查询的性能，您需要确保这些表位于缓冲区中，因此不会有IO会降低CPU使用率。

你也可以尝试使用azure中的内存oltp表来获取关键表

查询在Azure中执行速度缓慢的瓶颈是什么

1 个答案: