【发布时间】：2020-08-01 00:44:44
【问题描述】：
作为测试，我们最近开始向 Azure 中的读取横向扩展 SQL Server 发送一些查询。我们的主数据库是 40 核 BC。我们注意到一些性能非常差，查询的执行时间比我们的主数据库要长 10 倍或更长。
我假设对此我无能为力？没有查询存储，看起来没有任何方法可以调整数据库？
【问题讨论】：
标签： sql-server azure
【发布时间】：2020-08-01 00:44:44
【问题描述】：
我们在读取横向扩展副本时遇到了类似问题。我们将 Azure SQL vCore 40 业务关键用于 OLTP。经过无数小时的调试和监控，我们确定读取横向扩展副本受到主要写入次数的严重影响。
在我们的案例中，我们观察到读取横向扩展副本中的读取查询有大量 SOS_SCHEDULER_YIELD 等待类型，并且 CPU 使用率高达 100%。如果我们将相同的读取查询切换到主数据库，CPU 永远不会超过 30%，并且 SOS_SCHEDULER_YIELD 不是普遍的等待类型。
以下查询显示 SOS_SCHEDULER_YIELD 是读取横向扩展的主要信号等待时间，但不是主要的。
select * from sys.dm_os_wait_stats
order by signal_wait_time_ms desc
我们使用生产数据库的副本将问题简化为小型测试用例，只有 3 个读取查询、1 个繁重的写入查询和并行运行读取查询的 .NET 应用程序。我们使用了 12 个 vCore 关键业务数据库。
- 测试 1：在主节点上执行读取查询。结果：~ 1500 次读取查询/秒，主数据库中 sys.dm_db_resource_stats 中的 CPU 使用率为 60%
- 测试 2：在读取扩展时执行读取查询。结果：约 1500 次读取查询/秒，读取横向扩展时 sys.dm_db_resource_stats 中的 CPU 使用率为 60%
- 测试 3：在主节点上执行写查询并在主节点上执行读查询。结果：约 1500 次读取查询/秒，主数据库中 sys.dm_db_resource_stats 中的 CPU 使用率为 70%
- 测试 4：在主节点上执行写入查询，在读取横向扩展时执行读取查询。结果：约 800 次读取查询/秒，读取横向扩展时 sys.dm_db_resource_stats 中 100% 的 CPU 使用率和主要中 10% 的 CPU 使用率
Microsoft 支持和产品团队确认 Azure SQL 中当前复制模型中的自旋锁存在问题，并对我们的数据库进行了临时修复 - 将复制从并行切换到其他模型。这为我们解决了这个问题。我们不确定是否修复了所有数据库。
【讨论】：
或许在这篇文章中你会找到答案。
Connect to a read-only replica
只读副本的监控和故障排除 连接到只读副本时，您可以使用 sys.dm_db_resource_stats DMV 访问性能指标。要访问查询计划统计信息，请使用 sys.dm_exec_query_stats、sys.dm_exec_query_plan 和 sys.dm_exec_sql_text DMV。
【讨论】：