S-HR 假勤--排班修改请假重算sql性能优化

栏目:s-hr cloud知识作者:金蝶来源:金蝶云社区发布:2024-09-17浏览:1

S-HR 假勤--排班修改请假重算sql性能优化

问题描述:

    员工排班修改,请假单重算事务非常卡慢,报错信息如下:

image.webp

分析:

    1.由于红框内的sql查询时间过长,导致触发了超时报错,抓出sql格式化,如下图:

image.webp

      2.与客户了解到,那边使用的是sqlserver数据库,叫客户那边看了下这条sql的执行计划,如下:

image.webp

        可以看到该条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,查看这两个表的索引情况如下:

        image.webp

可以为表t_hr_ats_scheduleshift以及表T_HR_ATS_LeaveBillEntry分别建立联合索引,可以按照字段的选择性从大到小的方式组合;


综上所述,优化步骤如下:

image.webp

      


       

S-HR 假勤--排班修改请假重算sql性能优化

问题描述: 员工排班修改,请假单重算事务非常卡慢,报错信息如下:分析: 1.由于红框内的sql查询时间过长,导致触发了超时报错,抓...
点击下载文档
分享:
确认删除?
回到顶部
客服QQ
  • 客服QQ点击这里给我发消息