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