一个潜伏了 5 年的 bug

2016/08/18 · 开发 · 10 评论 · Bug, MySQL

分享到：

本文作者：伯乐在线 - usher2007 。未经作者许可，禁止转载！
欢迎加入伯乐在线专栏作者。

前两天策划反馈某项活动中，理论上大概千分之一中奖率的一个奖品，连续四次被同一个玩家得到了。他之前已经找了几个程序复查过代码，都说没啥问题，但是从概率上讲，肯定是有问题的，所以希望我“为程序员正名”。经过一上午的奋战，我也算不辱使命，找出了这个潜伏了5年的bug，也了解了关于mysql的一个潜规则。

整个业务场景大概是这样的（下面代码仅为示意，不可直接运行）：

首先，每个玩家报名的时候，向数据库中插入一行，记录下活动id（activity_id），玩家uuid（player_uuid），申请序号（apply_no）以及一些其他的玩家相关信息。

同时，在内存中维护一个整数，记录当前活动的申请总人数apply_total_num。同时使用这个整数来获得下一个插入行的apply_no。

第二，由策划填写的数据表导成数据结构表示奖励结构，即每个等级的奖励各有多少份，如下所示：

awards = {
	1: 1, 
	2: 15, 
	3: 50, 
	...
	}

awards = {

1: 1,

2: 15,

3: 50,

...

}

第三，当活动报名完毕时，根据当前的apply_total_num和总奖励份数sum(awards.values())，生成一个长度为总奖励份数的随机的apply_no序列。比如有10000人报名，总奖励分数是1000，那么我们有可能生成如下的一个包含1000个apply_no的序列：

lucky_apply_nos = [234, 123, 1356, 8765, 12, ...]

1	lucky_apply_nos = [234, 123, 1356, 8765, 12, ...]

第四，从MySQL数据库中取出lucky_apply_nos对应的uuid：

lucky_uuids = SELECT player_uuid FROM world_lottery WHERE apply_no IN lucky_apply_nos;

1	lucky_uuids = SELECT player_uuid FROM world_lottery WHERE apply_no IN lucky_apply_nos;

拿到lucky_uuids之后，根据awards对应分配奖励：lucky_uuids[0]对应1等奖，lucky_uuids[1]~lucky_uuids[15]对应2等奖，依此类推。

看上去没有什么问题吧。其实问题就出现在SELECT语句这里了。在这段流程中有一个想当然的推论，就是lucky_uuids的顺序是和lucky_apply_nos中的顺序一致的。但是，其实这里踩了MySQL的一个潜规则坑：
对于没有ORDER BY子句的SELECT语句，其返回顺序是和所使用的引擎有关：