当你的数据库变得越来越大，增长的交易数量使得服务器越来越难以承受它带来的压力时，你该怎么办？

　　首先想到的方案，就是scale out，横向扩容，即将数据库扩展到多个服务器之上。这一方案会涉及到数据库复制(在实际应用中较为复杂)和数据库分区。事实上，在进行横向扩容的时候，几乎所有实施者都需要对数据库进行某种程度上的重新设计，而这就导致与数据库相关联的应用程序都会受到影响。

　　这里讨论的情况也许并不是放之四海而皆准的，但是横向扩容往往要求技术人员在实施之前，进行大量的规划和分析工作。

　　SQL Server数据库横向扩容的主要方法包括了以下几点：

　　复制。这个想法的初衷就是要将数据库工作负载平均地分配到多个服务器上，这样每一个服务器都会有一个数据库副本。这往往会涉及到合并复制，而更新订阅的事务复制同样也是一种选择。

　　每种形式的SQL Server复制都会产生延迟，因此你不要期待每一个数据库副本在任何时刻都能保持一致。而从长远角度来看，维护数据库复制也是一件复杂的工作，特别是在服务器之间的连接不稳定的情况下。

　　其它复制。这里所谓的其它复制，就是指有第三方提供的复制工具。这个方式主要提供给那些对SQL Server不熟悉的人员，它的复杂度会更高一些，而且费用也相对昂贵。

　　分布式分区数据库。这种方法，就是将数据库的数据分配到多个服务器上，不同的表甚至同一个表的不同部分都会分布在不同的服务器上。数据库对象，比如分布式分区视图(DPV)，可以提供访问数据的方法，通过这样的方法，所有的数据就像在同一个服务器上一样。对于一些编写出色的应用程序，它们只通过视图和存储过程访问数据，你就可以使用这一方法而不用对应用程序进行改动。

　　第二种方案，也是相对简单的方案，就是scale up，纵向扩容。简单地说，实现纵向扩容需要：

• 　　更大的服务器
• 　　更多的内存需求(多很多)
• 　　64位处理器
• 　　更多的处理器插槽与核心
• 　　服务器中的其他应用尽量少，以免造成资源争用

　　当微软为SQL Server做基准测试时，他们使用的最大纵向扩容硬件，为一个16插槽、96核心、TB级内存的64位服务器。测试结果显示这样的系统，对于一个8TB的数据库可以每秒钟生成2000多个事务，而且碳排放量也是相当的惊人。总的来说，纵向扩容的成本要大过横向扩容，但是通常人们还是倾向于花钱买清闲，因此scale up还是目前的主流扩展方案。