记一次问题排查

1785年卡文迪许在实验中发现把不含水蒸气、二氧化碳的空气除去氧气和氮气后仍有很少量的残余气体存在。这种现象在当时并没有引起化学家的重视。 一百多年后英国物理学家瑞利测定氮气的密度时发现从空气里分离出来的氮气每升质量是1.2572克而从含氮物质制得的氮气每升质量是1.2505克。经多次测定两者质量相差仍然是几毫克。--- <氩气的发现> 点击查看更多

对账系统的核心计算部分在定时任务timetask项目中,其中python脚本从sql server中按规则获取并计算当天符合条件的记录,写入到mysql中;展示部分(店主端)属于早期项目,没有用golang,用php的lumen框架,从mysql相应表中查取数据

后来同事反应,店主端资金明细展示,出现重复或者漏项等情况.查看了数据库,数据本身并无问题,不存在重复或缺少,于是推出是展示部分出现了问题

• 看了一下sql语句,因业务要求,这段sql由几个union all拼接而成,然后有order by,再limit;于是推断每次请求查出的结果不同(每次顺序会变化),再经过limit分页,就出现了所谓的数据"重复"和"缺漏"

• 网上很多关于union all order by 导致乱序的问题,但我这段sql,并不会如此;

• 后来发现顺序发生改变的一个原因,是有几条记录order by的字段完全一样;看上去只需要再加一个order by的字段如id asc,就可以解决问题

但不想就此停止,因为看上去用navicat执行这段sql,无论多少次,结果顺序都是稳定的;为了深入研究,抽象化后建了两张表

CREATE TABLE `cui` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT '',
  `book` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '1', '宋江', '<水浒传>', '2018-07-11 00:00:00');
insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '2', '卢俊义', '<水浒传>', '2018-07-11 00:00:00');
insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '3', '吴用', '<水浒传>', '2018-07-11 00:00:00');
insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '4', '公孙胜', '<水浒传>', '2018-07-11 00:00:00');
insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '5', '关胜', '<水浒传>', '2018-07-11 00:00:00');
insert into `你的库名`.`cui` ( `id`, `name`, `book`, `create_time`) values ( '6', '林冲', '<水浒传>', '2018-07-11 00:00:00');

CREATE TABLE `shuang` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(255) DEFAULT '',
  `book` varchar(255) DEFAULT NULL,
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8

insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '1', '林黛玉', '<红楼梦>', '2018-07-11 00:00:00');
insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '2', '薛宝钗', '<红楼梦>', '2018-07-11 00:00:00');
insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '3', '贾元春', '<红楼梦>', '2018-07-11 00:00:00');
insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '4', '贾探春', '<红楼梦>', '2018-07-11 00:00:00');
insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '5', '史湘云', '<红楼梦>', '2018-07-11 00:00:00');
insert into `你的库名`.`shuang` ( `id`, `name`, `book`, `create_time`) values ( '6', '妙玉', '<红楼梦>', '2018-07-11 00:00:00');

• ***经过多次实践发现,用lumen或者pdo执行几次后,最开始几次一定会乱序,随着执行次数的增多,会渐"趋于稳定",这是个神奇的现象;为复现顺序会变,可多次修改表名 ***

• 在lumen中写一个方法测验:

• navicat中的执行结果如下,无论执行多次,返回值始终幂等如一

• 但此时还不能认为是lumen存有问题,也许是navicat做了什么处理,还需要查看执行原始sql的结果;见下图,执行多次亦始终如一

• 其实这里还有一个小问题,那就是虽然同样"稳定",但navicat和命令行执行结果,可能出现不一样的情况...即用navicat执行上面这段sql无论多少次,返回的结果始终如a不会改变;命令行执行这段sql无论多少次,始终如b,但a和b顺序可能不同;这是实践得出的一个非必现的诡异现象

• 在我准备给lumen提pr时,h哥提出,还要看看php的mysql扩展(在此即pdo)有无问题.框架的orm操作基于php的mysql扩展,如果上游数据即会变序,lumen这里肯定会每次执行顺序不同

• pdo直连数据库,代码及结果如下:

• 在pdo这一步,如果union all中order by的字段存在相同的情况,就会发生乱序;不知道这是扩展的bug,还是官方已说明如此,为此,需要和PECL进行沟通;