定时任务框架太多了，选个简单高可用的以为就安心用就完了，结果哈，最先发现这个问题是去年的12月31日，我以为是我们的业务有bug了，当天提了问题，发现只有我们的没执行，就不自信了，不了了之了，最近又发生了。
那总的给个原因吧，这次连带的是其他小分队的也没有执行，是2月26日
那么下午运维给出了原因。
原因如下：
1.运维人员发现 xxx机器上 （数据库磁盘 /home 超过90% ），进入数据库中查看到 数据库 xxljob 库中，发现 XXL_JOB_QRTZ_TRIGGER_LOG 约有 16.5 GB（王德发~） 的数据，可以表中部分时间点数据，没有减少磁盘使用空间。
该表解释是 调度日志表：用于保存XXL-JOB任务调度的历史信息，如调度结果、执行结果、调度入参、调度机器和执行器等等；
2.操作命令：如下语句，执行后约 20 min ，发现磁盘空间没有下降。
表：XXL_JOB_QRTZ_TRIGGER_LOG 约有 16.5 GB
执行过程中
代码语言：javascript复制 DELETE FROM XXL_JOB_QRTZ_TRIGGER_LOG WHERE trigger_time >= '2021-12-17 00:18:59' AND trigger_time <= '2021-12-18 23:59:20'；操作可能导致数据库 死锁或者CPU夯住了，导致 0 时执行的任务，没有执行成功。
解决方案：
目前生产环境 xxljob-amdin 数据库服务器（xxx）磁盘 总大小：27G 已使用：9.7GB 剩余约：17GB，需要合理评估一下数据增长量，数据库磁盘容量大小进行扩容。
业务定时任务高峰期都集中夜间，建议任务调度服务中的 XXL_JOB_QRTZ_TRIGGER_LOG 这张表保留最近一周的日志量，在业务低峰期每天早上：9:00 定时执行脚本。
我默默的看了眼我生产数据库的最大表，4个G是2000万左右，16-17G也就是我的4倍，那可是将近一个亿啊，这说明什么？他没按着业务中心去分表啊，把所有数据全放在一个表Allin了？别说你时间字段没建索引，就是建了索引看来一天日志量也不小啊，这一下就可能导致锁表？首先咱也是读过官方文档的，它不是支持动态分片的么，这删除时间定为每天9点，那那些每5分钟执行一次的任务是不是还得凉凉？
