我正在研究如何扩展 SQL Server 2008R2 的可能性。简单地扩大规模是不够的。
“p2p 复制”和“分布式分区视图”看起来很有趣，但都需要（多个？！）企业许可证，非常昂贵，而且都不是完美的解决方案。
一个非常简单的想法是：
Read from Random Server - Write to all Servers
很好地包装在一个事务中，以便如果它在所有服务器上没有成功，它可以被回滚。我担心如果一台服务器上出现问题或者因为一台服务器上的其他锁而等待，会出现一些严重的锁定问题。
一个非常相似的解决方案是：
Read from Random Server - Write to Server A (which replicates automaticly to all others)
这会更昂贵，因为需要标准许可证，而第一个可以使用 express 完成，但从性能方面来说会更好吗？这些自动复制的速度有多快？这一切有意义吗？还是有更好的方法？
答案1
设置从中央服务器到每个 Express 实例的合并复制；Express 不能充当发布者，但可以作为卫星，并且包括合并更新。
答案2
根据 OP 在上面的评论部分提供的答案，这听起来不像是一个横向扩展的解决方案。我认为您最好花时间查看以下内容：
1.) 数据库设计和查询性能 --> 分析此实例上 SQL 中运行的工作负载并确保其按预期执行。查找耗时超过预期的查询，查看所涉及的表和存储过程/SQL 代码的底层设计。
2.) 查看您在服务器上运行的资源。您是否已达到 SQL Express 的最大限制？如果是这样，那么我会考虑运行一些测试场景并分析工作负载，以查看升级到更高规格的服务器，也许升级到标准版或企业版以及增加的资源分配是否会有所帮助。您是否在基于 64 位的机器上部署？有多少内存？进行瓶颈分析以确定哪些瓶颈会减慢您的速度。
3.) 确保数据库维护工作正在进行（索引重建、统计信息更新和适当的备份维护 - 我经常发现供应商提供的 SQL Server Express 版本安装从未备份过，也从未进行过维护 -http://expressmaint.codeplex.com/寻找一个脚本来帮助自动化和安排其中一些任务）
4.) 您是否在同一台服务器上托管应用程序和 SQL Server 数据库引擎？现在可能是时候考虑将它们分开了。应用程序和 SQL Server 通常在系统资源方面具有竞争优先级，并且在同一台机器上通常不能很好地互补。测试一下。查看 perfmon 以了解影响。
如果完成所有这些更改后，您仍然遇到性能问题，您可能会考虑采用扩展方法，但我认为从长远来看，这些步骤对您和您的客户来说更为基本且成本更低。
答案3
在我看来，您需要进行一些 SQL 性能调优。如果数据库足够小，可以在 SQL Express 中运行，那么您很可能不需要配置一些大规模扩展设置。您可能只需要从索引调优开始，以修复性能不佳的查询并设置一些索引维护作业。