创新谈-王红波_2006年中国首届杰出数据库工程师 王红波

创新性应用：

分表+通行证：和一般的通行证一线之隔，但从长远的角度却提供了很大的方便。对于用户数量的暴增，或者需要将某个地方大量的用户引入系统，如果保障系统在数据量在数量级增长的时候，依然保证数据库的正常运行。我采用的是按照用户的唯一标志(用户ID)的范围对用户进行逻辑分区，各个范围的登陆读写，都由一个中间调度接口指向不同的表，这样分散数据量。但是我还加上一个通行证，只保存用户的ID和逻辑分区号，一方面解决了用户ID生成的统一要求，另外也让以后的扩展变得非常容易。理论上来看，按这个模式以后是可以无限拓展的。假如是照400万分一个逻辑区，400万的数据操作，只要代码比较合理，几乎不会产生阻塞，所以我选择了这个数字。用户增加400万已经是比较大的一个数字了，根据我的设计，只需要新建一个逻辑区，然后在中间调度过程新加入这个处理过程的流转，甚至可以提前加入这个过程，让下次在增长400万不用你做任何处理。

在我跟一些资深的数据库专家交流的时候，我也知道了几乎所有的大型平台，都使用的是数据库集群，用他们的话说，做了集群，基本不用优化，基本不用考虑数据库有瓶颈。的确，大量的硬件投入，的确是很直接的解决方法，但没有硬件条件的时候，靠优化操作，靠优秀的结构，也可以发挥出很强的性能。在他们知道我们这里用一台数据库服务器，支撑两个游戏平台，其中一个在线人数已在万人一上，他们都认为单PC级别的服务器，达到这样的功能，已经是奇迹了。不过即使到现在，数据库依然有优化的余地，也就是还有潜能可以发挥，或者这有限的硬件条件，对数据库工程师也是一种挑战。

行业借鉴经验：

我前面提到的，我所实践出来的数据库同步和用分表并且由统一接口生成通行证的方案应该有比较强的借鉴意义。数据同步方案的操作流程公布在我的blog 上之后，以后有很多朋友联系过我，说明他们有相同的需要。关于分表和通行证的方案，我在创新性应用里已经比较详细的说明了。

另外还有一点，就是要根据自己的情况，进行灵活的处理。我在工作的过程中，有这么个表，数据量约2000万，每天增长约150万，主要是写入操作。当然读操作只是相对小，但是一方面，写操作频繁的表不该多建索引，另外读也很重要，这个数据量如果不建立合适的索引，是没办法进行读操作的。那么我之前做了同步这个工作，我就让备份数据库上的表结构和主数据库这个表结构不同。我在备份数据库这个表建立了多个和查询条件关联的索引，由于只有10分钟的数据差别，所以读操作我直接用联接服务器指向了这个备份数据库。

应用难点技巧：

至于技巧这方面，网上有很多人整理了自己的看法。我觉得也是根据各自工作的特点，很多说法，也只是相对而言。我在工作的过程中，细节上，也有些自己的规则。

1．  代码习惯：写存储过程，前面写明功能，注释参数的含义，中间注释出各个代码段的含义。变量命名也根据类型有对应的规则。

2．  表的写入操作：主要是建立表的时候，不为空的字段我还是会设置默认值，要不很容易出现写入失败的情况，同结构表的生成避免使用select into 生成，因为它把约束和键信息会丢失的。插入表尽量避免insert …select ..这样的写法，应该用insert(字段1,2,3) values或者insert(字段,…) select …,让字段和输入值有对应关系，这样以后表进行修改的话，也不至于有些字段没有输入值而让相关的写入操作失败。

3．  在查询上，如果可能，尽量在备份库执行，并且尽量发挥索引的作用。关联的时候，也尽量用联接查询，避免用子查询，因为子查询效率明显要低很多。

4．  4

4．数据维护：对于数据产生数据量大的表，也写好定时清理过期信息的代码。这样把最新的数据放到一个表，比较老的数据放另一个表，对很多操作会比较方便的。