业务系统修改工号操作性能优化问题现象一个业务系统中有修改员工工号操作。刚开始上线时用户部门还能接受。随着时间推移大概两年左右该操作所需时间要大于半小时甚至1个小时还经常会导致锁表。问题分析与处理分析该操作代码发现主要做如下步骤。针对所有还有employee_no列明的表执行更新操作。大致操作如下update tablename set employee_nonew_xxxx where employee_noold_xxxx最开始由于employee_no列未加索引该步骤花费时间也较长。加上索引后提升到秒级完成。针对所有列名中同时含有employee和no的表判断相关列是否含有旧工号如果有替换成新工号。大致操作如下update tablename set aa_employee_bb_nofn_r(aa_employee_bb_no, old_xxx, new_xxxx ) where employee_noaa_employee_bb_nofn_s(aa_employee_bb_no, old_xxx, new_xxxx )。该步骤花费时间更长。其中fn_r和fn_s时函数分别将aa_employee_bb_no值根据逗号分隔后再判断是否存在旧工号。该操作无法使用到索引。经分析该步骤针对的表也包含了步骤1针对的表。于是检查步骤1相关的表发现其中所有表中employee_no列都只含有1个工号。于是修改代码将本步骤排除步骤1相关的表。修改后总体还需要十几分钟才能完成。于是再进一步分析剩下的所有表。发现有一些表记录相对较多大于1万条有的甚至大几十万条所以肯定会影响性能。于是查询所有表的aa_employee_bb_no字段发现只有8张表存在多个工号的情况其他都是只有1个工号。而且幸运的是还有多个工号的8张表数据量非常小。于是将这些表拆除2部分一部分按照步骤1的方式处理剩下8张表按照步骤2的方式处理。改造完成后总体时间缩短到10秒。
业务系统修改工号操作性能优化问题现象一个业务系统中有修改员工工号操作。刚开始上线时用户部门还能接受。随着时间推移大概两年左右该操作所需时间要大于半小时甚至1个小时还经常会导致锁表。问题分析与处理分析该操作代码发现主要做如下步骤。针对所有还有employee_no列明的表执行更新操作。大致操作如下update tablename set employee_nonew_xxxx where employee_noold_xxxx最开始由于employee_no列未加索引该步骤花费时间也较长。加上索引后提升到秒级完成。针对所有列名中同时含有employee和no的表判断相关列是否含有旧工号如果有替换成新工号。大致操作如下update tablename set aa_employee_bb_nofn_r(aa_employee_bb_no, old_xxx, new_xxxx ) where employee_noaa_employee_bb_nofn_s(aa_employee_bb_no, old_xxx, new_xxxx )。该步骤花费时间更长。其中fn_r和fn_s时函数分别将aa_employee_bb_no值根据逗号分隔后再判断是否存在旧工号。该操作无法使用到索引。经分析该步骤针对的表也包含了步骤1针对的表。于是检查步骤1相关的表发现其中所有表中employee_no列都只含有1个工号。于是修改代码将本步骤排除步骤1相关的表。修改后总体还需要十几分钟才能完成。于是再进一步分析剩下的所有表。发现有一些表记录相对较多大于1万条有的甚至大几十万条所以肯定会影响性能。于是查询所有表的aa_employee_bb_no字段发现只有8张表存在多个工号的情况其他都是只有1个工号。而且幸运的是还有多个工号的8张表数据量非常小。于是将这些表拆除2部分一部分按照步骤1的方式处理剩下8张表按照步骤2的方式处理。改造完成后总体时间缩短到10秒。
