数据库大数据量解决方案（转）

随着业务量的增大, 数据库DB服务器的负载现在维持在50-70%之间, 期间也开始出现些问题, 虽然马上解决了, 但是优化性能的问题已经迫在眉睫!
  根据我和同事的讨论, 现在有两种方案可取:
  一: 根据业务来拆分, 把当前DB的表根据功能的不同分别放到不同的数据库中, 如用户信息相关的放到A 用户信息DB服务器中, 资金相关的放到B 资金DB服务器中, 还有Log, 物品等也需要放到不同DB那里. 这种方式简单, 估计一星期可以搞定, 再加上测试, 对我们本来时间就不是很充裕的情况下来说, 可行性比较大, 但是, 考虑到原来DB中有许多事务是同时需要处理用户、资金和其他信息的， 现在分散在不同DB中， 这个事务的完整性等是个麻烦！
  二：另外一种考虑方式就是，根据用户来分， 每10W用户一个DB服务器，建立一个索引数据库， 引导不同用户去访问该用户所在的DB， 共通的数据可以放在一个服务器上，如果这些共通的数据也很多的话， 可以根据不同情况再来拆分（以我们网站为例，具体也是100种网络游戏一个DB，这样300个网络游戏的交易信息可以分散在3个DB）， 前期不考虑业务上的划分， 就是说方案一中的用户信息相关表和资金信息表、LOG表在每个DB都有， 但是因为对每个DB操作的用户分散在不同的DB中， 也可以优化性能。 就是这种方案需要花费的时间会多一点。 不过， 因为这种方式， 每个DB和共通数据所在DB的数据有点冗余， 我考虑用触发器来维持同步， 不过感觉触发器的效率不是很高... 所以还在考虑其他更好的方法！