Please answer some questions before submitting your issue. Thanks!
2.0.2
无慢SQL
当使用时间长了时候，数据表中的数据比较多，导致慢sql出现，如下的SQL，为数据库端监控到的慢sql，查询所有ID出来，这无疑是一个隐形的雷，使用时间越久，此查询的消耗越恐怖，望解决
ovfsdjhp16#
呃呃呃呃呃呃1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表，确定这个表的数据 在你们生产环境是否有必要保留，可以 定时任务清理此表 ，个人强烈 推荐 2 查看这个表自身的索引信息 show index from xxl_job_quartz_**log 看下那个字段没有建索引 就那三个筛选条件，但是从mysql 建索引的意义来讲，这种索引意义不大，因为这三个字段重复性太强，任务执行状态 调度结果，告警状态 并不推荐 3 升级版本，我看了你这个版本是19年发布的，这个版本和后续版本最大的不同是作者移除了quartz 这个框架 后续调度的源码是作者手写的 类似于 while(true) trigger 这种，但是你升级版本之后，估计运行一段时间后，依旧会存在慢sql ，作者新版本是 使用了xxl_job_log 表 ，默认了三个索引 id trigger_time 调度时间 hanlde_code执行状态
作者可能也是发现了这个问题，给这三个字段加了组合索引的，但是因为都是重复率很高的字段，还是慢SQLKEY idx_alarmstatus_id_handlecode_triggercode (alarm_status,id,handle_code,trigger_code)
应该可以考虑时间维度来过滤掉大部分无用数据，比如查出来所有启用状态下的JOB的执行周期，按最大的周期的2倍作为时间依据，避免全表过滤一遍
我刚用一周 在log百万的时候也没出现慢sql 和你同样的sql 走的I_handle_code索引也就是handle_code好像没毛病 我怀疑是你这个索引建多了 索引合并了 走错索引了 where前面加上 force index(I_handle_code)试试看 应该是有效的
huus2vyu17#
ds97pgxw18#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
trigger_code handler_code alarm_status 三个都加吧
针对这个sql handle_code就够了 查的是异常的id 区分度高量不大
是的，这个几个字段加索引意义不大，作者可能也是发现了这个问题，给这三个字段加了组合索引的，但是因为都是重复率很高的字段，还是慢SQLKEY idx_alarmstatus_id_handlecode_triggercode (alarm_status,id,handle_code,trigger_code)
idx_alarmstatus_id_handlecode_triggercode
alarm_status
id
handle_code
trigger_code
ghhkc1vu19#
okxuctiv20#
我2.2.1 版本 xxl_job_log 这个表作者是弄了三个索引的 id trigger_time. handle_code还有我觉得应该是 1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表
bqujaahr21#
ctehm74n22#
2sbarzqh23#
不行的，每小时查询270多次，每次平均执行时间都是>3.3s，alarm_status加了索引时间还多了0.2s，因为alarm_status字段无法过滤大量重复的值，所以索引意义不是很大，感觉他这个sql可以优化优化，加个时间维度，他现在这种查法，索引扫描了，数据量越大执行会越慢
看错了 他最新版本也有这个sql 只是改了个表名 单列索引加在handle_code上
pftdvrlh24#
5cg8jx4n25#
手动加索引？
他这个手动加索引也没用，他是把表里所有的id都查出来，数据量越大这个查询越慢，隐形的雷
zwghvu4y26#
hlswsv3527#
27条答案
按热度按时间ovfsdjhp16#
呃呃呃呃呃呃
1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表，确定这个表的数据 在你们生产环境是否有必要保留，可以 定时任务清理此表 ，个人强烈 推荐 2 查看这个表自身的索引信息 show index from xxl_job_quartz_**log 看下那个字段没有建索引 就那三个筛选条件，但是从mysql 建索引的意义来讲，这种索引意义不大，因为这三个字段重复性太强，任务执行状态 调度结果，告警状态 并不推荐 3 升级版本，我看了你这个版本是19年发布的，这个版本和后续版本最大的不同是作者移除了quartz 这个框架 后续调度的源码是作者手写的 类似于 while(true) trigger 这种，但是你升级版本之后，估计运行一段时间后，依旧会存在慢sql ，作者新版本是 使用了xxl_job_log 表 ，默认了三个索引 id trigger_time 调度时间 hanlde_code执行状态
作者可能也是发现了这个问题，给这三个字段加了组合索引的，但是因为都是重复率很高的字段，还是慢SQL
KEY idx_alarmstatus_id_handlecode_triggercode (alarm_status,id,handle_code,trigger_code)
应该可以考虑时间维度来过滤掉大部分无用数据，比如查出来所有启用状态下的JOB的执行周期，按最大的周期的2倍作为时间依据，避免全表过滤一遍
我刚用一周 在log百万的时候也没出现慢sql 和你同样的sql 走的I_handle_code索引也就是handle_code好像没毛病 我怀疑是你这个索引建多了 索引合并了 走错索引了 where前面加上 force index(I_handle_code)试试看 应该是有效的
huus2vyu17#
呃呃呃呃呃呃
1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表，确定这个表的数据 在你们生产环境是否有必要保留，可以 定时任务清理此表 ，个人强烈 推荐 2 查看这个表自身的索引信息 show index from xxl_job_quartz_**log 看下那个字段没有建索引 就那三个筛选条件，但是从mysql 建索引的意义来讲，这种索引意义不大，因为这三个字段重复性太强，任务执行状态 调度结果，告警状态 并不推荐 3 升级版本，我看了你这个版本是19年发布的，这个版本和后续版本最大的不同是作者移除了quartz 这个框架 后续调度的源码是作者手写的 类似于 while(true) trigger 这种，但是你升级版本之后，估计运行一段时间后，依旧会存在慢sql ，作者新版本是 使用了xxl_job_log 表 ，默认了三个索引 id trigger_time 调度时间 hanlde_code执行状态
作者可能也是发现了这个问题，给这三个字段加了组合索引的，但是因为都是重复率很高的字段，还是慢SQL
KEY idx_alarmstatus_id_handlecode_triggercode (alarm_status,id,handle_code,trigger_code)
应该可以考虑时间维度来过滤掉大部分无用数据，比如查出来所有启用状态下的JOB的执行周期，按最大的周期的2倍作为时间依据，避免全表过滤一遍
ds97pgxw18#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
trigger_code handler_code alarm_status 三个都加吧
针对这个sql handle_code就够了 查的是异常的id 区分度高量不大
是的，这个几个字段加索引意义不大，作者可能也是发现了这个问题，给这三个字段加了组合索引的，但是因为都是重复率很高的字段，还是慢SQL
KEY
idx_alarmstatus_id_handlecode_triggercode(alarm_status,id,handle_code,trigger_code)ghhkc1vu19#
呃呃呃呃呃呃
1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表，确定这个表的数据 在你们生产环境是否有必要保留，可以 定时任务清理此表 ，个人强烈 推荐 2 查看这个表自身的索引信息 show index from xxl_job_quartz_**log 看下那个字段没有建索引 就那三个筛选条件，但是从mysql 建索引的意义来讲，这种索引意义不大，因为这三个字段重复性太强，任务执行状态 调度结果，告警状态 并不推荐 3 升级版本，我看了你这个版本是19年发布的，这个版本和后续版本最大的不同是作者移除了quartz 这个框架 后续调度的源码是作者手写的 类似于 while(true) trigger 这种，但是你升级版本之后，估计运行一段时间后，依旧会存在慢sql ，作者新版本是 使用了xxl_job_log 表 ，默认了三个索引 id trigger_time 调度时间 hanlde_code执行状态
okxuctiv20#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
trigger_code handler_code alarm_status 三个都加吧
针对这个sql handle_code就够了 查的是异常的id 区分度高量不大
我2.2.1 版本 xxl_job_log 这个表作者是弄了三个索引的 id trigger_time. handle_code
还有我觉得应该是 1 楼主看下 这个表有多少数据 这个表应该是 xxl_job 保存任务调度执行日志的 一个表
bqujaahr21#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
trigger_code handler_code alarm_status 三个都加吧
针对这个sql handle_code就够了 查的是异常的id 区分度高量不大
ctehm74n22#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
trigger_code handler_code alarm_status 三个都加吧
2sbarzqh23#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
不行的，每小时查询270多次，每次平均执行时间都是>3.3s，alarm_status加了索引时间还多了0.2s，因为alarm_status字段无法过滤大量重复的值，所以索引意义不是很大，感觉他这个sql可以优化优化，加个时间维度，他现在这种查法，索引扫描了，数据量越大执行会越慢
看错了 他最新版本也有这个sql 只是改了个表名 单列索引加在handle_code上
pftdvrlh24#
新版都没这表还优化啥
好吧，那只能升级版本了
感觉问题不大 看这条sql的意思是 查询出还没判断是否决定报警的log 线程循环去捞的 每次捞出来的量不会很多 索引加到alarm_status上就可以解决
不行的，每小时查询270多次，每次平均执行时间都是>3.3s，alarm_status加了索引时间还多了0.2s，因为alarm_status字段无法过滤大量重复的值，所以索引意义不是很大，感觉他这个sql可以优化优化，加个时间维度，他现在这种查法，索引扫描了，数据量越大执行会越慢
5cg8jx4n25#
手动加索引？
他这个手动加索引也没用，他是把表里所有的id都查出来，数据量越大这个查询越慢，隐形的雷
zwghvu4y26#
新版都没这表还优化啥
好吧，那只能升级版本了
hlswsv3527#
新版都没这表还优化啥