Question

我的问题的快速摘要：在我的Azure SQL S0实例中，执行SELECT WHERE ColumnXYZ =＆＃39;％any％＆＃39;需要8:57分钟。在具有8,211,037行的表上（结果集= 929行）。在包含500,000行的表上，需要38秒。我的笔记本电脑（快速使用SSD）和8米线路上的相同表格需要0秒才能完成。

我知道由于规格可能存在差异，但我不了解其中的巨大差异 - 这些性能水平不允许我使用Azure SQL（我的数据库将被使用单个并发用户运行偶尔的大型查询）。此外，我担心升级到更高级别，因为我不需要DB快两倍或四倍 - 它需要快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上的非聚集索引。 ProgramNumber。 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运算符，查询的执行成本很高。基本上，DB必须查看表中的所有条目，以确定哪些是结果集的一部分。如果这是您的应用程序的典型查询，则可能需要考虑升级到更高的性能级别。

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

Azure SQL性能下降

1 个答案: