S-HR 假勤--排班修改请假重算sql性能优化
问题描述:
员工排班修改,请假单重算事务非常卡慢,报错信息如下:
分析:
1.由于红框内的sql查询时间过长,导致触发了超时报错,抓出sql格式化,如下图:
2.与客户了解到,那边使用的是sqlserver数据库,叫客户那边看了下这条sql的执行计划,如下:
可以看到该条sql主要是在于员工排班的排次表做循环遍历的时候,开销达到了100%,查询了下客户那边员工排班表(t_hr_ats_scheduleshift)的数据规模大概是700万数据量,而请假单分录(T_HR_ATS_LeaveBillEntry)的数据量才10万不到。
所以优化思路主要有以下两点:
降低表t_hr_ats_scheduleshift的有效数据规模:
分析以上业务sql可知,请假开始时间大于2022-12-15号的,考虑到跨天班的场景,员工排班表的考勤日期(FAttendDate)一定是大于2022-12-14号的,通过增加这个过滤条件,可以把t_hr_ats_scheduleshift表中700万数据量一下降低到55万,同时因为t_hr_ats_scheduleshift业务中只用到了FLastUpdateTime,FATTENDDATE ,FProposerID 三个字段,可以按照这种方式去创建一张临时表,用临时表的处理方式,相当于做了一个表中转,即直接把700万的表中转之后变成了55万;
为表t_hr_ats_scheduleshift相关的查询建立合适的索引:
上面的sql可知,与员工排班表(t_hr_ats_scheduleshift)直接发生关系的是请假单单分录表(T_HR_ATS_LeaveBillEntry),比较的字段主要包括:FLastUpdateTime,FATTENDDATE ,FProposerID,查看这两个表的索引情况如下:
可以为表t_hr_ats_scheduleshift以及表T_HR_ATS_LeaveBillEntry分别建立联合索引,可以按照字段的选择性从大到小的方式组合;
综上所述,优化步骤如下:
S-HR 假勤--排班修改请假重算sql性能优化
本文2024-09-17 00:30:15发表“s-hr cloud知识”栏目。
本文链接:https://wenku.my7c.com/article/kingdee-shr-61423.html