标签：
网站规模到了一定程度之后，该分的也分了，该优化的也做了优化，但是还是不能满足业务上对性能的要求；这时候我们可以考虑使用主从库。主从库是两台服务器上的两个数据库，主库以最快的速度做增删改操作+最新数据的查询操作;从库负责查询较旧数据，做一些对实效性要求较小的分析，报表生成的工作。这样做将数据库的压力分担到两台服务器上从而保证整个系统响应的及时性。如果还无法满足业务需求，我们就要考虑创建服务器群，这里我们不做考虑！
1. 打开sql server企业管理器，在对象资源管理器里面选择复制à本地发布，右键选择新建发布
2. 打开新建发布向导，点下一步，选择发布数据的数据库
3. 我们选择Test数据库，并点击下一步，选择发布类型
4. 点击下一步，选择要发布的对象，这里我们只对表进行发布
5. 点击下一步进入筛选数据设置，这里我们要复制表的所有数据所以不做设置
6. 点击下一步，指定何时运行快照，我们选择初始话数据，并选择默认的运行快照频率
7. 继续下一步，设置快照代理的运行账户，我们选择sql server agent账户
8. 点击下一步选择创建发布，再次点击下一步设置发布的名称
9. 点击完成，完成发布的设置，并创建发布，现在在本地发布出新添加了我们创建的发布
现在成功创建了发布，我们还需要创建订阅：在本地订阅文件夹上右击新建订阅，通过向导可以很容易的创建订阅，创建订阅时可以选择以发布者推送或者订阅者主动的方式创建。具体步骤如下：
1. 通过右键菜单打开新建订阅，点击下一步，选择我们刚刚创建的发布作为订阅源
2. 选择是以推送还是以主动请求的方式同步数据，我们选择主动订阅
3. 设置执行分发代理的账户
4. 设置代理请求同步的频率
5. 设定是否立即做数据的初始化操作
6. 完成创建订阅
创建完成之后，我们可以通过在主库表中插入n条数据，然后在从库中查询的方式验证复制是否成功。
在Sql server2005中的复制创建起来很简单，我们需要根据业务需要设定复制的类型和同步的频率。
下面我们具体看下主从库的几个使用场景和一个简单的小例子。
主从库之间是一种发布订阅的关系，发布者和订阅者之间并非实时同步的，通常会有几分钟的延时，更有甚者会有几个小时的延时。所以我们需要通过合理的使用来避开有延时这个问题。我们希望主库尽可能的少参与查询，来提高写的及时性；同时要让从库在不影响读出数据的准确及时的前提下尽可能的分担主库的压力。主从两个库需要在配置文件中配置两个连接字符串，CONN_Master和CONN_Slave。我们需要设定一些规则决定当前的查询应该从主库查还是需要从从库查。这个规则没有定式，只能根据业务需要来确定。下面我举几个例子来说明：
1. 以豆瓣读书书的详细页为假定场景，你可以点击这里看下页面的结构（我不是豆瓣的技术，在这里只是拿这个页面举例）
我们来分析呈现这个页面需要的数据和这些数据的实效性要求
1） 书的详细信息 时效性要求：要求及时
2） 豆瓣成员的常用标签 实效性：不需要很及时
3） 喜欢读这本书的人也喜欢读的书 属于分析数据，不需要很及时
4） 最新书评 要求及时
5） 读这本书的几个用户 及时性不高
6） 喜欢这本书的人常去的小组 属于分析数据不需要很及时
从上面的分析可以看出只有1），4）两项数据需要从主库读，而2），3），5），6）为非及时数据从从库读取即可。当然我们可以对这些实效性不高的数据做缓存处理。
2. 以论坛帖子列表页面为假定场景，玩论坛的人都喜欢顶贴，把自己的帖子顶到第一页让更多的人关注，而对于50页之后的帖子则反读的人很少；我们可以根据这个业务逻辑特征来决定在用户访问前50页帖子列表数据时从主库读，而当用户访问超过50页之后的数据时则从从库进行查询。
3. 以订单为例，通常超过三个月的订单就不会再有变化了，假定我们把订单号设计为日期格式时，根据订单号去查询订单时就可以根据订单号来决定该访问主库还是从库。
举了几个适用的场景，我们以第三个场景为例，写一段简单的示意代码看下
正确的使用主从库，可以很好的提升系统的性能。使用主库还是从库的选择权决定在业务逻辑的手里。
标签：
原文地址：http://www.cnblogs.com/whtydn/p/4950555.html
