定时任务框架种类繁多，选择一个简单且高可用性强的框架本以为可以安心使用，结果却让人失望。去年12月31日首次发现这个问题，当时以为是我们的业务存在bug，提出了问题，但发现只有我们的任务未执行，信心受挫，问题不了了之。最近问题再次发生。
这次不仅我们，其他小分队的任务也没有执行，日期是2月26日。下午运维给出了原因。
原因如下：
-
运维人员在xxx机器上发现数据库磁盘/home使用率超过90%，检查xxljob数据库，发现XXL_JOB_QRTZ_TRIGGER_LOG表中有约16.5 GB的数据，导致磁盘空间未能释放。
该表是调度日志表，用于保存XXL-JOB任务调度的历史信息，如调度结果、执行结果、调度入参、调度机器和执行器等。
-
执行以下命令后，约20分钟，磁盘空间并未减少：
DELETE FROM XXL_JOB_QRTZ_TRIGGER_LOG WHERE trigger_time >= '2021-12-17 00:18:59' AND trigger_time
该操作可能导致数据库死锁或CPU卡住，导致0时执行的任务未能成功执行。
解决方案：
目前生产环境xxljob-admin数据库服务器（xxx）磁盘总大小为27G，已使用9.7GB，剩余约17GB。需要合理评估数据增长量，考虑数据库磁盘容量扩容。
业务定时任务高峰期集中在夜间，建议在任务调度服务中的XXL_JOB_QRTZ_TRIGGER_LOG表保留最近一周的日志量，并在业务低峰期每天早上9:00定时执行脚本。
我默默地查看了生产数据库的最大表，4GB约2000万条数据，16-17GB是我的4倍，接近一个亿。这说明什么？他们没有按照业务中心进行分表，而是将所有数据都放在了一个表中？别说时间字段没建索引，就是建了索引，一天日志量也不小，这可能导致锁表？我们也读过官方文档，它不是支持动态分片的吗？如果删除时间定为每天9点，那些每5分钟执行一次的任务是不是也会受到影响？
