绩效部同事反映部分员工绩效在查询时无法显示,并给出了两个工号。这两个工号对应绩效全部正常审批完成,但在绩效管理模块却无法显示。绩效管理采用分页查询,查询语句为:
语句中包含一个union,主要用于查询历史绩效(历史绩效指与绩效表结构完成相同,但主要用于存储OA上线前在moss上所填写的绩效数据,用于员工自行查询)。
截取的sql语句如下:
select Performance.id from (SELECT Performance.id, f_nd, f_khqj, f_staffname, f_staffid, f_bm, f_zw1 as f_zw, f_sqrq, f_zf3, f_dqjxfs, f_kpi, f_gs, ifnull(f_df1,0)f_df1, ifnull(f_df2,0)f_df2, ifnull(f_df3,0)f_df3, ifnull(f_df4,0)f_df4, ifnull(f_df5,0)f_df5, ifnull(f_df9,0)f_df9, ifnull(f_df10,0)f_df10, ifnull(f_df11,0)f_df11, ifnull(f_df12,0)f_df12, ifnull(f_df13,0)f_df13, ifnull(f_df17,0)f_df17, ifnull(f_df18,0)f_df18, ifnull(f_df19,0)f_df19, ifnull(f_df20,0)f_df20, ifnull(f_df21,0)f_df21, ifnull(f_zpf1,0)f_zpf1, ifnull(f_zpf2,0)f_zpf2, ifnull(f_zpf3,0)f_zpf3, ifnull(f_zpf4,0)f_zpf4, ifnull(f_zpf5,0)f_zpf5, ifnull(f_zpf9,0)f_zpf9, ifnull(f_zpf10,0)f_zpf10, ifnull(f_zpf11,0)f_zpf11, ifnull(f_zpf12,0)f_zpf12, ifnull(f_zpf13,0)f_zpf13, ifnull(f_zpf17,0)f_zpf17, ifnull(f_zpf18,0)f_zpf18, ifnull(f_zpf19,0)f_zpf19, ifnull(f_zpf20,0)f_zpf20, ifnull(f_zpf21,0)f_zpf21, f_txrzjzgname, f_jxzzdf, f_jxdj, f_jxxs, f_zf1, f_zf2, Performance.releaseDate, zjzginfo.staffName AS zjzg, case when exec.status='2' then '结束' when ISNULL(activityName)=1 then '绩效填写' else task.activityName END activityName, exec.id as processExecutionId, GROUP_CONCAT(distinct staff.staffname) as dqspr, CONCAT('[',GROUP_CONCAT(distinct CONCAT('{userName:','"',task.createUserCode,'"',',taskid:','"',task.taskId,'"','}')),']') as userNameandTaskid , case when activityName='start1' then 1 when activityName='工作行为考核人确认' then 2 when activityName='重新填写' then 3 when activityName='填写人自评' then 4 when activityName='考核人评估' then 5 else 6 END sortno ,'普通' as jxlx from T_DYMC_20150211170947 Performance left join tree_node tree on Performance.f_staffid=tree.id left join t_bpm_process_execution exec on Performance.id=exec.pkValue left join t_bpm_process_define process on process.id=exec.processDefineId left join t_bpm_process_task task on exec.id=task.processExecutionId and task.status='0' left join t_per_staffinfo staff on task.createUserCode=staff.staffcode and staffStatus='zz' LEFT JOIN t_per_staffinfo zjzg ON Performance.f_staffid = zjzg.staffid LEFT JOIN t_per_staffinfo zjzginfo ON zjzg.directLeaderCode = zjzginfo.staffid where tree.leftId >= (select leftId from tree_node treenode where treenode.id= 'FX004613') and tree.rightId <= (select rightId from tree_node treenode where treenode.id= 'FX004613') GROUP BY pkValue ) Performance where Performance.f_staffName = '潘宇' and Performance.id != 0
该语句经走读并未发现明显问题。
在数据库中进行比较,发现以下问题
id(uuid)规律与其他明显不同;
releaseDate为空;
releaseDate用于最新更新时间,做为锁并行并发控制;之前有一篇博文介绍会签并发控制的。
releaseDate是timestamp,对timeStamp的了解是1.有确定的表示时间的范围;2.相当于一个trigger,会随着数据变化取当前时间;3.mysql允许存在多个timestamp的属性,如有多个只有第一个可以正常更新当前时间;
参看:mysql之TIMESTAMP(时间戳)用法详解
查看创建表的语句,只保留releaseDate的创建
show create table t_dymc_20150211170947 .. `releaseDate` timestamp NULL DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, ..
releaseDate:第一,允许空,第二,创建时默认为空,第三,每次更新均自动更新为当前时间;
查询数据库的commit机制
show engine innodb status like '%commit%'
所有的事务提交都是autocommit,考虑到可能出现这样的问题,即在审批时,表单表可能被锁,导致该事务未提交成功,而其他表的更新均成功,所以代码中如未对事务做准确的控制,这种情况是可能出现的。但如接受这思路,就无法解释三次提交均锁表的情况。
使用如下语句查看lock情况
show status like ‘%lock%’
查找锁表,未发现问题。
由于以上主要针对releaseDate为什么为空和id的创建规律为何突变。由于反复确认两个问题无果,以及两个问题均未导致流程的审批出现明显问题。所以,解决方向变为主攻查询语句。
经进一步确认,该查询是个分页查询,结果条数与下方显示的总数条数不同,始终少一,少的就应该是问题数据;使用compare对queryList和queryCount进行比较,发现两者不同之处有四;
querylist在将流程数据和历史数据进行联合时使用union,queryCount使用的是unionAll。该思路一度让我对之前对两者最基本区别的认知产生动摇。实际上经过测试也并不是union/unionAll导致。参看:union和union all的区别
queryList多了一个where id != 0该代码由其他已离职同事编写,用意不明(可能是因为在查询历史数据时,返回的Id不是其真正的id,而是统一为"0",这段代码也莫名其妙);
queryList多了一个order;
queryList中在一个返回属值“pxtl”前多了两个汉字,两个汉字也未加""
分别对以上进行测试,发现只有2去掉之后问题不再出现
经测试,发现sql有如下规律
在sql中,当id为字符串且首字符是字母时,id !=数字0,当id的首字母为数字时,id=数字0。经确认,6-7日晚至6-8日填写的所有绩效,其id的生成规律均与其他明显不同;首字符为f,其他首字符为2,所以查询不到。目前已将id!=0拿掉,经测试问题解决。
经一步查询id开头非数字的,发现均在6月7日至6月8日,该问题产生原因目前不明。