Mikel
[转载]Sql效能优化总结（续）- 架构调整篇 – Jerry Tian – 博客园.
SQL效能优化总结（续）–架构调整篇
看到几个博友对笔者的这个话题挺感兴趣，今天终于可以静下心来继续总结，废话少说，入正题。
从SQL Server2005到SQL Server 2008和现在的SQL Server2012，微软好像一直没有推出负载均衡组件，如类似Oracle RAC的技术，不能实现负载均衡。由于数据库的高并发及横向扩展是经常遇到的问题，不少用户遇到这样的情况时考虑的方案是移植到Oracle平台，采用 RAC来解决问题。这是个很艰难的过程，成本相信也将是巨大的。也考虑过一些第3方方案。如：Moebius等，由于具多限制，也未能采用。所以只能利用 MS现有技术了，介绍前先简单提下MS的SQL平台的几种技术：
故障转移集群
Microsoft Cluster Server(MSCS)是一个提升可用性的技术，当一台服务器出现故障是可以段时间切换到其他服务器继续提供应用服务，不能实现负载均衡。
SQL Server 2005镜像和快照
该技术利用镜像来提高可用性，利用快照服务提供数据访问服务。
镜像是大家都熟悉的一个概念，快照是SQL Server 2005中引入的新特性。快照是某一个时间点上的数据库的克隆。快照的生成一般只需要几秒钟，创建快照时其实没有复制任何数据。对镜像数据库创建了快照 DB，快照DB就可以给用户提供数据服务器。但是由于是快照，实时性较差，所以使用时要考虑是否适合一些实时应用。如果要想把负载分散在主数据服务器和镜 像服务器上，就要阶段性的创建快照。
复制、订阅
SQL Server提供了复制技术（Replication），可以使现读写分离。有几种方式，基于快照、基于log和复合方式等，由于在本例中没有使用，在此不再赘述。
数据服务器架构调整：
由于公司几年前的应用逐渐增多，已经出现过一次系统效能问题，当时对数据服务器的硬件已经升级过一次了，但是由于近几年系统的不断增加，又一次达到 临界点，但是目前的数据服务器在一般的企业应用中基本已经算是顶级配置了，再进行硬件升级的话，一定需要一笔不小的开支。经过分析，其实现有系统中一部分 功能是不需要进行对数据的更新的，只需要读取数据（一些报表、查询等），于是决定把现有的服务器架构进行调整，进行读写分离，把一些唯读即可满足的功能， 转移到其他服务器，以此来分担现有的主数据服务器的压力。
原来的数据服务器架构，就是一般的客户端直解连接连接数据服务器，如下图：
调整后的数据服务器架构：
其实目前这个架构还不是最佳方案，采用复制技术应该在当前Case应该是最合适的，一是对系统的修改量最小，只要改变数据连接就可以达到目前的效 果。二是复制技术相对目前采用的镜像+快照方案技术上也是相对成熟的，但是之前由于出现过一次故障，所以该方案没被采纳，直到现在都还在愤愤不平， （TMD公司政治，不说了），数据服务器架构调成后，客户端的一些唯读功能，可以直接连接到镜像服务器，但是镜像是一种数据容错方案，若你提供镜像服务器 上更新数据的话，可能会发生意想不到的情况（具体没有测试，不妄加评论），而我们又想提供数据服务给客户端，该怎么办呢？SQLServer2005提供 了快照功能，建立快照DB后就象访问原DB一样，可以增删改，快照DB刚开始创建时其实是没有数据的，只是记录变化的记录信息，具体快照DB的原理，大家 可另外了解，在此不再赘述。
这种方案有个缺点，创建了快照DB后，用户访问快照DB相当于访问创建快照DB的那个时间点的原有DB。
例如：原DataBase名字为DB1，在上午10：00整时创建了快照DataBase，名字为DB2，用户访问DB2就相当于访问10：00点整时的DB1，快照嘛，顾名思义。
由于以下2个原因，就需要我们不断的删除旧的快照DB，创建新的快照DB提供数据访问服务。
- 客户端的用户永远想访问最实时的数据
- 快照DB的数量不能太多，因为增加快照DB会增加服务器负荷（因为他要同步源DB和每一个快照DB的差异数据）
由快照DB提供给用户访问的数据同原来的服务器中的数据有一个时间差，我们定为10分钟，这个时间差对一般的应用用户还是可以接受的。
经过迁移一些耗费服务器资源（主要是逻辑读，这个是服务器操作的瓶颈）较大的报表或查询到镜像服务器，有效减少了主数据服务器的压力，事实证明效果 还是比较明显的。经过以上努力，合理分担了主数据服务器的压力到其它不是很重要的服务器上，从某种意义上来说达到了负载均衡的效果。到此，关于数据服务器 架构调整先告一段落，后续再介绍具体的sql优化。
未完待续。
