绩效部同事反映部分员工绩效在查询时无法显示，并给出了两个工号。这两个工号对应绩效全部正常审批完成，但在绩效管理模块却无法显示。绩效管理采用分页查询，查询语句为：

     	
     
      		select * from (		select		Performance.id,			f_nd,		f_khqj,		f_staffname,		f_staffid,		f_bm,		f_zw,		f_sqrq,		f_zf3,		sum(f_zpf1+f_zpf2+f_zpf3+f_zpf4+f_zpf5+f_zpf9+f_zpf10+f_zpf11+f_zpf12+f_zpf13+f_zpf17+f_zpf18+f_zpf19+f_zpf20+f_zpf21)f_dqjxfs,		sum(f_df1+f_df2+f_df3+f_df4+f_df5+f_df9+f_df10+f_df11+f_df12+f_df13+f_df17+f_df18+f_df19+f_df20+f_df21)f_syfszh,		f_txrzjzgname,		f_jxzzdf,		f_jxdj,		f_jxxs,		f_zf1,		f_zf2,		releaseDate,		zjzg,		activityName,       processExecutionId,      dqspr,      userNameandTaskid ,       sortno, '普通'jxlx  from (SELECT 		
      		
      		
      		
      		
      		) Performance		
       		group by id		 union all		select Performance.* from (			SELECT '1'as id,						f_nd,f_khqj,f_staffname,f_staffid,f_bm,f_zw,f_sqrq,f_zf3,f_dqjxfs,f_syfszh,f_txrzjzgname,f_jxzzdf,f_jxdj,f_jxxs,f_zf1,f_zf2,releaseDate,zjzg,activityName,processExecutionId,dqspr,userNameandTaskid,sortno,jxlx					FROM						t_per_his_performance Performance					)Performance LEFT JOIN tree_node tree ON Performance.f_staffid = tree.id         
             
      			= (select leftId from tree_node treenode where treenode.id= #{currentUserStaffid}) and  tree.rightId <= (select rightId from tree_node treenode where treenode.id=#{currentUserStaffid})				]]>		           	  ) Performance where  Performance.id !=0  		
       	
      
     

   语句中包含一个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

   该语句经走读并未发现明显问题。

   在数据库中进行比较，发现以下问题

1. id（uuid）规律与其他明显不同；

2. releaseDate为空；

   releaseDate用于最新更新时间，做为锁并行并发控制；之前有一篇博文介绍会签并发控制的。

   releaseDate是timestamp，对timeStamp的了解是1.有确定的表示时间的范围；2.相当于一个trigger，会随着数据变化取当前时间；3.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进行比较，发现两者不同之处有四；

1. querylist在将流程数据和历史数据进行联合时使用union，queryCount使用的是unionAll。该思路一度让我对之前对两者最基本区别的认知产生动摇。实际上经过测试也并不是union/unionAll导致。参看：

2. queryList多了一个where id != 0该代码由其他已离职同事编写，用意不明（可能是因为在查询历史数据时，返回的Id不是其真正的id,而是统一为"0"，这段代码也莫名其妙）；

3. queryList多了一个order；

4. 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日，该问题产生原因目前不明。