Azure SQL 性能缓慢答案

【问题标题】：Azure SQL slow performanceAzure SQL 性能缓慢
【发布时间】：2015-04-21 21:25:27
【问题描述】：

我的问题的快速总结：在我的 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）？

【问题讨论】：

SQL Azure 产品团队已收到警报，很快就会有人回复

标签： performance azure azure-sql-database

【解决方案1】：

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

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

【讨论】：

感谢您的评论 - 它让我想到了正确的方向。昂贵的查询确实是问题所在。我现在提出的一个中间解决方案是通过创建一个包含所有唯一值“ProgramName”的新表来改进查询。然后，我运行相同的查询，但随后在唯一值表和原始表之间进行连接。现在，我可以在 26 秒内运行相同的查询。仍然没有准备好生产，但更接近它需要的地方。我现在将尝试规范化表（例如，唯一值表的外键）以获得更好的性能。

【解决方案2】：

尝试 azure 搜索功能，这将提高搜索查询性能。

http://azure.microsoft.com/en-us/documentation/services/search/

【讨论】：

感谢您的提示 - 但我更喜欢在 T-SQL 中进行这项工作。我正在使用适用于常规表/视图的应用程序生成工具（Iron Speed Designer）。乍一看，使用这个搜索工具似乎需要我进行许多超出我能力范围的自定义。
要将 Azure SQL 数据库与 Azure 搜索的丰富搜索功能相结合，可以使用 Azure SQL 的 Azure 搜索索引器。更多详情请查看azure.microsoft.com/en-us/documentation/articles/…。