20万人同时在线的游戏数据库要如何设计

些表是不能分库的， 比如账号表， 你分电信一区，网通一区， 但是登陆的时候查的账号表都是同一张表， 你不可能让玩家在电信一区注册一个账号， 到网通一区再注册一个账号。 然后，角色数据表，可能还有公会数据表，拍卖行数据表等等，也就是各区独有的数据，那就是每区一个数据库。 设计起初就是角色数据一张表，一行数据就是一个玩家的数据（字段包括：等级，经验等等这些基础数据，身上的装备（一个blob），背包（一个blob），仓库（一个blob），任务数据（一个blob），好友（一个blob），等等） 然后根据实际需要，比如数据库自身的压力， 那么可能是按行拆分表，比如拆4张表，userid%4模是多少，就在哪张表中 比如服务器的逻辑划分（下面会举例）， 不同的数据的更新的频率（这个主要是考虑数据的重要程度，比如玩家的装备是重要数据，更新频率比较高，是不能丢失的数据；而玩家的任务，这个数据如果回档可以丢失，大不了让玩家重新完成一次任务，那么更新频率比较低）。 可能会再按列拆分这张表： 比如拆成，玩家基础数据（攻击防御身上的装备）一张表，玩家背包仓库一张表，玩家好友一张表，等等按照实际需要划分 举几个例子： 玩家登陆之后，进入角色选择画面的时候，你要显示玩家已经创建的角色，同时要显示这个玩家身上的装备，拿在手上的武器，可能这个武器是强化过的，是要发光的，是吧。这个时候你不可能把玩家所有数据全部读出来，只需要读他的基础数据，多少级，身上的装备是什么，就可以了。玩家点进入游戏，才将剩余数据一并读到内存，包括背包啊仓库啊什么的。 再比如，你们拍卖行是一个单独的服务器，因为拍卖行可能会涉及到大量搜索，甚至是汉字的模糊匹配，一般为了不影响正常逻辑的效率，可能会单独拿出来。这个时候，拍卖行这个服务器也是不需要这个玩家的所有数据的，只需要玩家寄售在拍卖行的装备，所以数据库的设计上，玩家寄售在拍卖行的装备就单独拆分出来作为一个表。 再比如，邮件服务器，邮件一般不要求及时，为什么呢，因为邮件数据里面可能包含很多汉字，尽管其实这些汉字一般玩家都不会填的，所以邮件数据包推给客户端的时候，要比普通的移动，攻击包，可能会大很多，这个是从网络的效率来考虑，为了不影响普通的移动、攻击包的网络的收发效率，邮件数据会在这个玩家角色不动的时候，比如站在安全区摆摊的时候才推给客户端。比如wow也就是半小时以内收到，那么逻辑上邮件服务器可能也就是单独的一个服务器，那么显然这个服务器也是不需要这个玩家的所有数据的，那么从数据库的设计上来说，邮件也就是单独一张表就可以了。 诸如此类。