数据库扩容能使计算操作能处理更大负载，使负载更高、性能更优。SQL Server 2008支持两种扩展策略：Scale up（纵向扩容）和Scale out（横向扩容）。这两种扩展策略都是专门为提升基于SQL Server应用的整体性能而设计，但它们的优势和采用的技术完全不同。

　　SQL Server中的纵向扩容（Scale up）

　　纵向扩容是最直接的扩展策略，这种方法主要用于提高单机SQL Server服务器处理更大负载的能力。采用这种策略，我们要使用更高性能的处理器，更多的CPU和连接数，更多的内存和磁盘空间。从理论上来说，纵向扩容的扩展策略提升性能的空间很大，但事实上，有多少用户能配备TB数量级RAM的64-way计算机呢？此外，达到一定的压力点后（取决于所运行的应用类型），内存和处理器资源不再是主要瓶颈，如开始出现网络连接之类的问题。不幸的是，简单地给计算机增加网卡并不一定能提升它的网络连接性能。

　　纵向扩容策略的另一个局限是它只支持单机服务器。也就是说，我们不能把它用在分布式数据环境下。然而，在很多情况下，性能可以通过复制多份数据拷贝到可能是更廉价和更低性能的多台计算机得到提高。这种方法常用于Web farm（网络场），通过选用不太昂贵（甚至低廉的）硬件，横向扩容（scale out）策略会比纵向扩容策略更加节约成本。

　　优先考虑横向扩容（Scale out）

　　横向扩容策略关注更具挑战性的问题。它不像Web server那样简单批量复制静态网页到另一台Web server。在SQL Server中，数据处在不断的变化中。

　　许多人可能是第一次接触SQL Server 2008自带的可用于实现横向扩容(Scale out)的复制功能。SQL Server提供了多种复制模式，让我们先来看看低延迟优先的模式（lowest latency:低延迟，尽可能保持复制的数据及时更新）。它们是事务复制（Transactional replication）和合并复制（Merge replication）。

　　事务复制（Transactional replication）和合并复制（Merge replication）这两种技术都需要通过快照（snapshot——本质上就是现有数据库的镜像拷贝）手工创建当前数据的副本来启动。两种技术都不停地分析SQL Server事务日志并给副本数据提交这些事务操作，因为所有数据库变更都记录在事务日志中（一般数据库产品都是这样的）。通过抓取事务然后发送到数据副本，数据副本就可以重建数据，进而提供持续的、准确的数据拷贝。

　　然而，这两种复制方式本质上都是单向的。它们是为使副本保持及时更新而设计，但并不保证两份可写的数据拷贝之间的同步。我们可以在两个数据库拷贝之间建立两套单向复制机制，然后有我们自己来处理它们之间的变更冲突。用事务复制（Transactional replication）处理这个问题很简单，因为大部分最近的变更都有时间戳记录。从这一点上来看，事务复制（Transactional replication）略胜一筹。

　　合并复制（Merge replication）是专门为多份副本之间同步数据的场合设计的。这种复制方式支持用户创建自定义的合并机制来处理多份副本之间的变更冲突。我经历过合并复制模式在3-4台高速运转的服务器上工作的情形，这种模式的同步效果非常好，当然前提是服务器之间有高速网络连接（比如：专用的T1线路）。如果网络连接速度慢，合并复制模式维持各相关服务器之间准确拷贝的能力也会降低。我个人曾经经历过花大量时间调试和处理复制过程中的问题（包括复制失败的问题）。我得声明，在横向扩容机制中，这可不是我喜欢做的。

　　有时候用户的大部分数据库变更是针对某一份数据副本（我们称之为“master副本”），其他数据副本基本是只读的。复制机制对这种情况下的同步处理的非常好。但这并不是真正的横向扩容（Scale out）,真正的横向扩容模式中，所有数据库副本是平等的，它们都要处理读和写。

　　既然我们谈到这个话题，尤为重要的是，要记住SQL Server 2008的日志传送（log shipping）和数据库镜像（database mirroring）并不是明确地为实现横向扩容专门设计。这两个特性都是为了通过提供热后备（hot spare）提高SQL Server的可靠性而设计的，它们既不提供双向复制，也不为横向扩容提供低延迟选择。