我们有一个用ASP.NET编写的基于Intranet浏览器的应用程序，以MS SQL Server作为数据库后端。我们的一位客户始终在两个节点上设置可用性组。我们的应用程序请求（通过可用性组侦听器）路由到主R / W节点，我们的客户端使用R / O节点进行自定义报告（水晶报告）。
随着用户数量的增加，我们正在遇到性能问题-主要与CPU相关。
我们希望客户增加更多的CPU，而他们希望我们开始将只读查询路由到R / O节点。
我们真的很犹豫，因为这将是应用程序更改，而实际上是不平凡的更改：
我们知道，报告是发送到R / O节点的理想情况（减少负载，阻塞等）。是否建议通过将只读查询发送到只读节点来实现负载平衡？
在我看来，我们需要负担得起的一切。同步R / O节点需要花费一些时间，因此我们需要始终了解我们可能正在读取旧数据。例如，用户单击“保存”按钮，保存记录后，我们重新读取要显示的记录列表。我假设我们必须去R / W节点以确保新记录将在那里。正确吗？
如果我们将查询发送到R / O节点，是否会降低系统的健壮性？如果一个节点崩溃，则另一个节点需要能够承受自身的负载。是否有建议的方案，在有意义的情况下将请求发送到R / O节点，何时不发送？
答案 0 :(得分：4)
最好将与报告相关的查询（仅）发送到辅助节点，以使CPU密集型报告不会降低在线数据库的性能。您的交易不会受到非交易用途的影响。
但是，这并不意味着您需要在辅助节点上进行所有R / O查询。假设您有一个事务性操作，该操作首先需要使用带行锁的select操作，而不应该从被动节点执行读取操作，而在主动节点上不执行DML操作。
我们可以说所有操作查询都可以从“主动”节点查询，而“被动”节点更适合用于长时间运行的报告。
对于第二个问题，如果第二个节点配置为异步，则是的，可能会有一些延迟，并且在日志传送失败的情况下，可能会看到旧数据。
对于第三个问题，它实际上取决于当前/将来/高峰时间的系统负载。这很难说。它还取决于预算，如果您负担得起，则可以再增加1个节点。一切取决于。但是请记住，RDBMS系统对于水平缩放不是很可行。