mysql会话变量和分区的坑

Posted by Thh on October 7, 2016

最近在新东家做审批系统,业务逻辑和工作流引擎都严重依赖mysql。其中业务逻辑部分大量用到存储过程,几乎所有核心dal都是用存储过程实现的。使用存储过程的优势是对于复杂的数据插入和更新操作效率很高。如果不使用存储过程,一个复杂的操作可能要请求多次数据库才能完成,但使用存储过程只需要请求一次,节省网络请求开销。但存储过程的坏处也很明细:不方便测试和调试。我们前一阵就碰到一个存储过程的bug,困扰了一阵。

某字段莫名其妙被篡改

有一天,同事发现数据库里面存的某个字段和原始申请单里面的字段不一样。而且奇怪的是,并非所有的申请单都是这样,有的是对的,有的不对。我检查了所有可能插入和修改该字段的代码,发现总共只有两个地方会写入该字段,并且这两个地方都是新增记录,不会修改。按理说只要存储过程参数传递正确,该字段就会正确地写入,并且不再变化。但事实却是,这两个地方写入的两种记录都会不确定性地出现字段被篡改的问题。

凭直觉,这种不确定性出现的问题,有可能是线程安全问题引起的。一开始,我们首先怀疑是参数在某个地方被非线程安全的访问,导致被诡异修改。排查代码,我们发现代码逻辑没有问题,不存在这种可能性。那只可能是存储过程的问题,后来终于找到原因。

这个bug是这样产生的。我们数据库里有一些码表,用来定义一些业务相关的类型,比如商品类型表(goods_type),它的定义类似这种:

id code description
-2 XER code有误
0 A 日用品
1 B 家电
2 C 厨房电器

用户的申请单中会包含商品类型信息(商品类型code),申请单保存到数据库的时候,会为每件商品存储一条记录,记录中包含该商品在商品类型表中的id。

用于保存商品信息部分的存储过程中有类似这样的语句:

select id into @goods_id from good_type where code=@goods_code;
if @goods_id = NULL then
	set @goods_id = -2;
end if

上面语句中@goods_id@goods_code都是会话变量,会在同一个会话中共享。@goods_code是从存储过程参数中得到的商品code。

@goods_code是一个在goods_type中找不到的code时,上面的select语句不会修改@goods_id的值,因此@goods_id的值会是上一次修改过后的值。如果当前会话之前的语句恰好修改过@goods_id,那该商品保存的商品类型id就会“莫名其妙“的被篡改。如果当前会话之前的语句没设置过@goods_id变量,那@goods_id值为NULL,就会执行后面的if语句。由于我们使用数据库连接池来访问数据库,连接会被复用,同一个会话就执行多条不同的语句,所以就会不确定性的出现字段被篡改的现象。

有两种方式修复该bug,一是在select语句前加上初始化语句set @goods_id = NULL;,这样每次使用前都保证会重新初始化变量;另一种方式是改成使用局部变量,不用会话变量。

mysql分区的坑

前一阵我们发现mysql写入、删除压力大,于是决定对其中一个关键表分区,缓解压力。该表有varchar(64)类型的主键,并且主键的生成策略类似UUID。我们使用mysql的key函数按主键分区,一开始设置分区数为64,发现所有的数据全分到一个区。刚开始怀疑是分区语句的问题,但经过确认,分区语句没啥问题。后来调整分区数,发现分区数为奇数时分区比较均匀,偶数有问题。

'c7e74234-40c7-11e6-a64b-7ce9d3efdb89', 
'c7e74232-40c7-11e6-a64b-7ce9d3efdb89', 
'c7e74230-40c7-11e6-a64b-7ce9d3efdb89',
'c7e609a5-40c7-11e6-a64b-7ce9d3efdb89', 
'c7e609a3-40c7-11e6-a64b-7ce9d3efdb89'

观察生成的主键,发现主键中间和后面的部分都一样,只有前面部分不同,猜测key函数分区实现和后面部分关系比较大。有空看看源码分析一下具体原因。