Azure SQL Server读取横向扩展性能

Question

作为测试，我们最近开始向Azure中读取的横向扩展SQL Server发送一些查询。我们的主要数据库是40核心BC。我们已经注意到，与执行主数据库相比，执行查询所花费的时间要长10倍或更长，因此性能有些差。

我假设对此无能为力？没有查询存储，看起来没有任何方法可以调整数据库？

Answer 1

我们在读取横向扩展副本上遇到了类似的问题。我们将Azure SQL vCore 40 Business Critical用于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 Business Critical数据库。

• 测试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中的CPU使用率在横向扩展中为100％，在主数据库中为10％

Microsoft支持和产品团队确认Azure SQL中的当前复制模型中的自旋锁存在问题，并临时修复了我们的数据库-将复制从并行模式转换为其他模式。这为我们解决了这个问题。我们不确定修复是否适用于所有数据库。

Answer 2

可能在本文中您会找到答案。

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。