记一次问题排查

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

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


记一次问题排查_第1张图片 记一次问题排查_第2张图片

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

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

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

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

记一次问题排查_第3张图片

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

CREATE TABLE `cui` (
  `id` int(11NOT NULL AUTO_INCREMENT,
  `name` varchar(255DEFAULT '',
  `book` varchar(255DEFAULT 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(11NOT NULL AUTO_INCREMENT,
  `name` varchar(255DEFAULT '',
  `book` varchar(255DEFAULT 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中写一个方法测验:

记一次问题排查_第4张图片 记一次问题排查_第5张图片 记一次问题排查_第6张图片 记一次问题排查_第7张图片
  • navicat中的执行结果如下,无论执行多次,返回值始终幂等如一
记一次问题排查_第8张图片
  • 但此时还不能认为是lumen存有问题,也许是navicat做了什么处理,还需要查看执行原始sql的结果;见下图,执行多次亦始终如一
记一次问题排查_第9张图片
  • 其实这里还有一个小问题,那就是虽然同样"稳定",但navicat和命令行执行结果,可能出现不一样的情况...即用navicat执行上面这段sql无论多少次,返回的结果始终如a不会改变;命令行执行这段sql无论多少次,始终如b,但a和b顺序可能不同;这是实践得出的一个非必现的诡异现象

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

记一次问题排查_第10张图片 记一次问题排查_第11张图片
  • pdo直连数据库,代码及结果如下:

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

本文由 mdnice 多平台发布

你可能感兴趣的:(后端)