2023年7月21日发(作者：)

quartz定时任务（数据库需要的表）Quartz将Job保存在数据库中所需表的说明

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 的信息

quartz 持久化数据库表格字段解释建表,SQL语句在quartz-1.6.6docsdbTables⽂件夹中可以找到,介绍下主要的⼏张表：

表qrtz_job_details: 保存job详细信息,该表需要⽤户根据实际情况初始化

job_name:集群中job的名字,该名字⽤户⾃⼰可以随意定制,⽆强⾏要求

job_group:集群中job的所属组的名字,该名字⽤户⾃⼰随意定制,⽆强⾏要求

job_class_name:集群中个note job实现类的完全包名,quartz就是根据这个路径到classpath找到该job类

is_durable:是否持久化,把该属性设置为1，quartz会把job持久化到数据库中

job_data:⼀个blob字段，存放持久化job对象

表qrtz_triggers: 保存trigger信息

trigger_name: trigger的名字,该名字⽤户⾃⼰可以随意定制,⽆强⾏要求

trigger_group:trigger所属组的名字,该名字⽤户⾃⼰随意定制,⽆强⾏要求

job_name: qrtz_job_details表job_name的外键

job_group: qrtz_job_details表job_group的外键

trigger_state:当前trigger状态，设置为ACQUIRED,如果设置为WAITING,则job不会触发

trigger_cron:触发器类型,使⽤cron表达式

表qrtz_cron_triggers:存储cron表达式表

trigger_name: qrtz_triggers表trigger_name的外键

trigger_group: qrtz_triggers表trigger_group的外键

cron_expression:cron表达式

表qrtz_scheduler_state:存储集群中note实例信息，quartz会定时读取该表的信息判断集群中每个实例的当前状态

instance_name:之前配置⽂件中ceId配置的名字，就会写⼊该字段，如果设置为AUTO,quartz会根据物理机名和当前时间产⽣⼀个名字

last_checkin_time:上次检查时间

checkin_interval:检查间隔时间

===========================================================================================前⾔Quartz默认提供了11张表，本⽂将对这⼏张表做简要的分析。表信息

共11张表，前6张都是关于各种triggers的信息，后⾯包括job，悲观锁，调度状态等信息；相关表操作在类StdJDBCDelegate中，相关sql语句在StdJDBCConstants中；_blob_triggers⾃定义的triggers使⽤blog类型进⾏存储，⾮⾃定义的triggers不会存放在此表中，Quartz提供的triggers包括：CronTrigger，CalendarIntervalTrigger，DailyTimeIntervalTrigger以及SimpleTrigger，这⼏个trigger信息会保存在后⾯的⼏张表中；_cron_triggers存储CronTrigger，这也是我们使⽤最多的触发器，在配置⽂件中做如下配置，即可在qrtz_cron_triggers⽣成记录：

表达式指定了每隔6秒执⾏⼀次，然后指定了要执⾏的task，task指定了要执⾏的业务，运⾏之后可以查看数据表：

myScheduler是在定义SchedulerFactoryBean时指定的名称，其他字段都可以在上⾯的配置中找到；_simple_triggers存储SimpleTrigger，在配置⽂件中做如下配置，即可在qrtz_simple_triggers⽣成记录：

指定了开始延迟时间，重复间隔时间已经重复的次数限制，查看表如下：

TIMES_TRIGGERED⽤来记录执⾏了多少次了，此值被定义在SimpleTriggerImpl中，每次执⾏+1，这⾥定义的REPEAT_COUNT=5，实际情况会执⾏6次，具体可以查看SimpleTriggerImpl源码：

timesTriggered默认值为0，当timesTriggered > repeatCount停⽌trigger，所以会执⾏6次，当执⾏完毕之后此记录会被删除；_simprop_triggers存储CalendarIntervalTrigger和DailyTimeIntervalTrigger两种类型的触发器，使⽤CalendarIntervalTrigger做如下配置：

CalendarIntervalTrigger没有对应的FactoryBean，直接设置实现类CalendarIntervalTriggerImpl；指定的重复周期是1，默认单位是天，也就是每天执⾏⼀次，查看表如下：

提供了3个string类型的参数，2个int类型的参数，2个long类型的参数，2个decimal类型的参数以及2个boolean类型的参数；具体每个参数是什么含义，根据不同的trigger类型存放各⾃的参数；_fired_triggers存储已经触发的trigger相关信息，trigger随着时间的推移状态发⽣变化，直到最后trigger执⾏完成，从表中被删除；已SimpleTrigger为例重复3次执⾏，查询表：

相同的trigger和task，每触发⼀次都会创建⼀个实例；从刚被创建的ACQUIRED状态，到EXECUTING状态，最后执⾏完从数据库中删除；_triggers存储定义的trigger，以上定义的三个triggers为例，分别是：firstSimpleTrigger，firstCalendarTrigger和firstCronTrigger，运⾏之后查看数据库：

和qrtz_fired_triggers存放的不⼀样，不管trigger触发了多少次都只有⼀条记录，TRIGGER_STATE⽤来标识当前trigger的状态；firstCalendarTask每天执⾏⼀次，执⾏完之后⼀直是WAITING状态；firstCronTrigger每6秒执⾏⼀次状态是ACQUIRED状态；firstSimpleTrigger重复执⾏6次后状态为COMPLETE，并且会被删除；_job_details存储jobDetails信息，相关信息在定义的时候指定，如上⾯定义的JobDetailFactoryBean，查询数据库：

JOB_DATA存放的就是定义task时指定的jobDataMap属性，所以此属性需要实现Serializable接⼝，⽅便持久化到数据库；_calendarsQuartz为我们提供了⽇历的功能，可以⾃⼰定义⼀个时间段，可以控制触发器在这个时间段内触发或者不触发；现在提供6种类型：AnnualCalendar，CronCalendar，DailyCalendar，HolidayCalendar，MonthlyCalendar，WeeklyCalendar；以下使⽤CronCalendar为例：

定义了⼀个排除每隔5秒的CronCalendar，然后在firstCronTrigger中指定了calendarName，并且需要在SchedulerFactoryBean中定义calendars；因为firstCronTrigger每6秒执⾏⼀次，⽽CronCalendar排除每隔5秒，所以会出现firstCronTrigger在第5次触发的时候需要等待12秒，结果如下：

查询保存在数据中的CronCalendar：

CALENDAR存放的是CronCalendar序列化之后的数据；_paused_trigger_grps存放暂停掉的触发器，测试⼿动暂停firstCronTrigger，代码如下：

启动之后延迟4秒后暂停firstCronTrigger，这⾥传递的参数group，然后查看数据库：

因为已经⼊库，所以重启之后firstCronGroup还是处于暂停状态，firstCronTrigger不会运⾏；_scheduler_state存储所有节点的scheduler，会定期检查scheduler是否失效，启动多个scheduler，查询数据库：

记录了最后最新的检查时间，在ties中设置了CHECKIN_INTERVAL为1000，也就是每秒检查⼀次；_locksQuartz提供的锁表，为多个节点调度提供分布式锁，实现分布式调度，默认有2个锁：

STATE_ACCESS主要⽤在scheduler定期检查是否失效的时候，保证只有⼀个节点去处理已经失效的scheduler；TRIGGER_ACCESS主要⽤在TRIGGER被调度的时候，保证只有⼀个节点去执⾏调度；总结