数据库表设计：
因为要把这么多访问量分担到不同的服务器里，原先的数据库表设计肯定不会合适。初步的想法是根据游戏的逻辑模块，将不同模块的数据库表拆分到各个服务器里，如果按照上面的服务器预估得到的结论是4~6组服务器，实际上这个方案还是可行的。但如果是20组服务器的话，除非是一台服务器一张数据库表，但这的设计会造成数据表太分散，在处理事务的时候，会跨多个数据库
策略类webgame一般的主要模块为：建筑物和资源、军事、英雄、物品、帮会、交易、地图。根据这些模块的应用场景，可以将数据库表分为2种类型，一种是属于玩家的数据，另外一种是公共数据。
1. 属于玩家的数据是指玩家个人说拥有的基地、资源、军事单位、物品等数据，它们都是围绕着玩家而产生的。
2．公共数据则是指由多位玩家共同组合而产生的数据，例如：账户信息、帮会、地图等。
这里划分两种数据的目的是在于他们的数据库表的划分。对于公共数据，则采用单一服务器，单一数据库表处理的方式来处理。例如帮会模块和地图模块就准备分别用3台服务器来存储各自对应的数据库表。而对于玩家的数据，则根据用户ID采用一定的划分方式，将玩家数据打散到各个服务器里（http://blog.zhaojie.me/2010/03/sharding-by-id-characteristic.html）。
（数据表的结构划分）
用户表和其单表的设计思路：
这里所说的单表是指在逻辑上部队数据库表做拆分，程序在访问时只访问一个数据库。当然这只是逻辑上的单一，根据实际上的访问压力，可以将数据库文件作水平切割分布在不同的文件分区和服务器里。这部分的数据库表设计继续沿用之前的设计方案就可以了。
对于用户信息，帮会信息等数据，实际上插入和更新的频率不会太高，更多的是在查询上，因此这部分的设计重点应该是在缓存上。从以前的资料里得知Memcache服务器每秒可以响应4w次的读请求，用一台Memcache就能处理好用户和帮会信息的缓存处理。
