公司的Principle给出的高性能数据库设计，总觉得别扭

这几天在公司做一个对性能要求极高的大容易数据库的一个功能的设计。公司的Principle给出的方案看上去有点非主流。想听听大家的意义。这个也许可以作为高性能数据库设计的Best Practice。

 

要做的功能，就是游戏里常见的排行榜的数据库。大概要有如下的几个信息。

 

userId	oldRating	curRating	Rank
Int	Int	Int	Int

 

每个user有一个数据项。User的设计容量有1000万（不多了，热血江湖号称有4000万注册用户）。

 

由于性能原因。排行榜并不能是实时的。所以给用户看的排行榜，总是一段时间之前生成的旧榜。所以表中的oldRating是真正显示给用户看的Rating值，Rank值就是根据oldRating计算出来的排名。而curRating保存的是用户当前最新的Rating值。而不回显给用户，只是为下次计算Rank提供最新的数据。

 

主要的分歧在于，每次如何计算Rank值？我的建议是直接用Merge语句和Rank函数，可以很快地进行计算。1000万数据，只要3.5分钟就可以全部更新完。然后公司的Principle认为这个方案不可行。

 

Principle的方案是，把数据整个导出到另一台电脑上，在另一台电脑上排序，计算Rank，然后再用这个计算出来的数据更新数据库。

 

原因如下：

1.       他认为Merge语句运行时会锁表。使得在进行数据更新时，用户就无法获取排行榜。

2.       我解释说Merge用的是行锁，他又说“I don't believe you. And”，计算过程会很耗数据库服务器CPU。导出到另一台电脑上，就可以分担服务器的负载，能更好地进行分布式运算。

 

我没有话说了，因为他是对的。（而且我的确不是很确定，如果数据更大的话，锁会不会提升到页或表。到多大会提升？）

 

我写了一个程序试了一下，程序写得不好，运行时间比较长。但是理论上，最快可以只用4分钟，的确不比直接在数据库内部进行运算慢多少。但是运算是分布式的。

 

补充一下。我们的服务器据说会有64G的内存。CPU每个至少是4核。

 

我的疑问就是，这样做真的值得吗？ 真的应该这样做吗？这个方案是个数据库的经典模式吗？