performance - Azure SQL 性能缓慢

Question

我的问题的快速摘要:在我的 Azure SQL S0 实例中，对包含 8,211,037 行(结果集 = 929 行)的表执行 SELECT WHERE ColumnXYZ = '%anything%' 需要 8:57 分钟。对于具有 500,000 行的表，需要 38 秒。我的笔记本电脑上的同一张表(SSD 速度很快)有 8m 行，需要 0 秒才能完成。

我知道由于规范可能存在差异，但我不明白巨大的差异 - 这些性能级别不允许我使用 Azure SQL(我的数据库将由单个并发用户使用偶尔运行大型查询)。另外，我对升级到更高层持谨慎态度，因为我不需要数据库速度提高两倍或四倍 - 它需要速度提高 500 倍。如果我做错了什么，有什么想法吗？或者在 Azure SQL 标准层中根本不可能获得更快的结果？高级级别对我来说不具有成本效益，因为数据库大部分时间都处于空闲状态。我不是数据库专家，但我会尝试在下面提供一些相关详细信息 - 请告知我是否应该添加更多详细信息。

表架构:

CREATE TABLE [dbo].[TestTable](
    [ID] [int] IDENTITY(1,1) NOT NULL,
    [PartNumber] [nvarchar](50) NULL,
    [Name] [nvarchar](450) NULL,
    [ProgramName] [nvarchar](450) NULL,
    [URL] [nvarchar](450) NULL,
    [ProgramNumber] [nvarchar](450) NULL,
    [Date] [datetime] NULL,
PRIMARY KEY CLUSTERED 
(
    [ID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

PartNumber、Name、ProgramName 上的非聚集索引。节目编号。 ID 上的聚集索引。

查询:

SELECT [PartNumber]
      ,[Name]
      ,[ProgramName]
      ,[URL]
      ,[ProgramNumber]
      ,[Date]
  FROM [dbo].[TestTable]
  where ProgramName like '%test%'

执行计划(设置 SHOWPLAN_ALL ON)第一列:

[removed original query as it takes up too much space
  |--Nested Loops(Inner Join, OUTER REFERENCES:([db1].[dbo].[TestTable].[ID], [Expr1002]) OPTIMIZED WITH UNORDERED PREFETCH)
       |--Index Scan(OBJECT:([db1].[dbo].[TestTable].[IX_TestTable_ProgramName]),  WHERE:([db1].[dbo].[TestTable].[ProgramName] like N'%test%'))
       |--Clustered Index Seek(OBJECT:([db1].[dbo].[TestTable].[PK__TableVie__3214EC277B422279]), SEEK:([db1].[dbo].[TestTable].[ID]=[db1].[dbo].[TestTable].[ID]) LOOKUP ORDERED FORWARD)

执行计划(设置 SHOWPLAN_ALL ON)其他列:

EstimateRows    EstimateIO  EstimateCPU AvgRowSize  TotalSubtreeCost
28671.36    NULL    NULL    NULL    181.9502
28671.36    0   0.1198463   3281    181.9502
28671.36    73.67498    9.032298    2015    82.70728
1   0.003125    0.0001581   1275    91.89737

数据库正在开发中，因此没有其他用户/查询正在运行。在Azure门户仪表板中，我看到今天的DTU峰值(当我测试时)是68.01%，因此DTU容量似乎不是问题。地区:美国东部

我真的很困惑 - 非常欢迎任何帮助!我可以做些什么来改进我的查询吗？或者我应该考虑另一个云提供商(使用 MySQL)？

Answer 1

由于您在 where 子句中使用 LIKE 运算符，该查询的执行成本很高。基本上，数据库必须查看表中的所有条目，以确定哪些是结果集的一部分。如果这是您的应用程序的典型查询，您可能需要考虑升级到更高的性能级别。

如果您可以预测查询何时运行，则可以针对这些特定时间点升级到更高的性能级别，然后再降级数据库。这样您就可以利用 SQL 数据库的按小时计费。