sql2005 负载问题
数据库为：sql2005
我们数据库的主要操作是验证注册码，卡的数量是不断上升的，而且每张卡每分钟可能会去验证多次，验证完成后，可能需要修改这张卡的信息。

现在单个数据库遇到瓶颈了，想多增服务器，请问我要用到什么技术，有什么好的解决办法？

我在网上看了关于sql2005 数据同步多服务器的技术，一台发布服务器，多台订阅服务器，可以实现数据同步。
多台服务器分流验证，这样就会导致订阅服务器也要修改数据，似乎不符合。

请问我应该怎么做？
------解决方案--------------------
可以在一台发布服务器上去修改数据，而验证主要是查询数据，这个可以在订阅服务器上去查询
------解决方案--------------------
mark 很好很实际的问题！说不定哪天就碰到类似问题了。
你说的订阅发布我觉得应该是属于高可用性的范畴，应该不是性能负载平衡方面的。
------解决方案--------------------
一般的数据库复制技术，主要是实现读写分离的，往往是一台写，多台读
------解决方案--------------------
你的需求应该考虑将库拆分到多个服务器，上层通过自定义路由表来判断到哪台数据库服务器去验证数据。
------解决方案--------------------
一般的数据库复制技术，主要是实现读写分离的，往往是一台写，多台读 
------解决方案--------------------
我觉得可以考虑一下分布式计算，或者合并复制，主要思路还是把负载分摊到多台机器上
------解决方案--------------------
可以根据逻辑关系分拆啊，比如分成A，B，C，D库，不同的库对应不同的卡号区间。
------解决方案--------------------
可以在一台发布服务器上去修改数据，验证主要是查询数据
------解决方案--------------------
我先假想一下你们的业务模式，再按我假想的模式提出解决方案。
假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态

这时如果你们被卡号无限增加的问题困扰，最应该做的是把大部分验证完的卡号放到其它的表或库中，从而保证可用卡号的数量被控制在某个能接受的范围内。

具体的实现可以用程序代码或作业完成，只要有足够的存储和合理的流转策略，性能不会是问题。
------解决方案--------------------
在做决定之前，先详细了解你所处的环境。
1、现在有多少卡，
2、注册码多次验证，平均每张注册卡验证多少次？
3、卡不断增长，每次增长范围是多少？
4、服务器真的存在瓶颈，瓶颈在哪里？CPU？内存？IO？
5、普通手段：T-SQL语句优化，索引优化，表分区，这些有没有尝试去做过？是否有效果？

最后才是硬件优化。
------解决方案--------------------

引用:

Quote: 引用:

我先假想一下你们的业务模式，再按我假想的模式提出解决方案。
假设你们的业务流程是 内部开通可用卡号--用户持凭证验证卡号--更新卡片状态

这时如果你们被卡号无限增加的问题困扰，最应该做的是把大部分验证完的卡号放到其它的表或库中，从而保证可用卡号的数量被控制在某个能接受的范围内。

具体的实现可以用程序代码或作业完成，只要有足够的存储和合理的流转策略，性能不会是问题。

我们有这个处理，卡过期后，用户可以清理过期注册码，清理后，转移到另外一张日志表。
主要的瓶颈是用户验证太频繁了，1分钟之内1张卡可以有多次验证。

验证主要是查询？ 有多少是会修改的呢？
------解决方案--------------------

引用:

Quote: 引用:

可以根据逻辑关系分拆啊，比如分成A，B，C，D库，不同的库对应不同的卡号区间。

 

我本地测试了下复制订阅，发布服务器修改数据后，要大概3、4秒中后订阅服务器的数据才会更新。本地没有跑任何程序，为什么数据会滞后这么久

在那个计划中是，选的是每1秒，就复制不
------解决方案--------------------
因为我昨天也配置了一个同步和订阅，里面的复制间隔最小是每1秒，不知道你是不是选择了这个设置呢

因为你说你的服务器上没有跑程序，照理应该是马上就能同步过去的，昨天我设置的是1分钟间隔，基本上插入数据后，马上查询订阅服务器，数据就通不过去了