有同事反应，测试环境的定时任务无法自动执行了，但是可以手动执行。
于是我检查了一下生产环境的任务，正常执行，那就奇了怪了，检查了一下配置，也没有啥子问题。当时由于忙，再说也是测试环境没那么重要，手动执行一下就是了，所以一直没有管。
今天，得空检查了一下，quartz的各个表数据。相应的表说明如下：
QRTZ_CALENDARS 以 Blob 类型存储 Quartz 的 Calendar 信息
QRTZ_CRON_TRIGGERS 存储 Cron Trigger，包括 Cron表达式和时区信息
QRTZ_FIRED_TRIGGERS 存储与已触发的 Trigger 相关的状态信息，以及相联 Job的执行信息 QRTZ_PAUSED_TRIGGER_GRPS 存储已暂停的 Trigger 组的信息
QRTZ_SCHEDULER_STATE 存储少量的有关 Scheduler 的状态信息，和别的 Scheduler实例(假如是用于一个集群中)
QRTZ_LOCKS 存储程序的悲观锁的信息(假如使用了悲观锁)
QRTZ_JOB_DETAILS 存储每一个已配置的 Job 的详细信息
QRTZ_JOB_LISTENERS 存储有关已配置的 JobListener 的信息
QRTZ_SIMPLE_TRIGGERS 存储简单的Trigger，包括重复次数，间隔，以及已触的次数
QRTZ_BLOG_TRIGGERS Trigger 作为 Blob 类型存储(用于 Quartz 用户用 JDBC创建他们自己定制的 Trigger 类型，JobStore 并不知道如何存储实例的时候)
QRTZ_TRIGGER_LISTENERS 存储已配置的 TriggerListener 的信息
QRTZ_TRIGGERS 存储已配置的 Trigger 的信息 1）首先检查了一下 qrtz_triggers 表的TRIGGER_STATE 字段，发现都是ERROR，说明定时任务执行中有错误。
TRIGGER_STATE 字段显示任务的属性大概状态有这几种：
WAITING:等待
PAUSED:暂停
ACQUIRED:正常执行
BLOCKED：阻塞
ERROR：错误
2）本来系统中有17条任务，检查生产环境也是17条任务，但是测试环境竟然多出10条异常的任务。
3）SELECT COUNT(*) FROM qrtz_simple_triggers 查询生产和测试分别为0和10条。
4）最终分析可能是这十条数据导致的，因为测试环境为了方便开发，多个开发人员都是连接测试数据库的。具体不清楚是如何导致这些垃圾数据库。
5）果断删除 这两张表多余的十条数据，然后UPDATE qrtz_triggers SET TRIGGER_STATE='WAITING' 更新状态为等待。
等待结果~~~~
