本文为您介绍TTL表冷数据清理算法以及如何管理清理任务。
版本限制
按行归档的版本要求
引擎版本为MySQL 5.7时，实例版本必须是polardb-2.4.0_5.4.19-20240927_xcluster5.4.19-20240920及以上。
引擎版本为MySQL 8.0时，实例版本必须是polardb-2.4.0_5.4.19-20240927_xcluster8.4.19-20240924及以上。
按分区归档的版本要求
引擎版本为MySQL 5.7时，实例版本必须是polardb-2.5.0_5.4.20-20250328_xcluster5.4.20-20250221及以上。
引擎版本为MySQL 8.0时，实例版本必须是polardb-2.5.0_5.4.20-20250328_xcluster8.4.20-20250304及以上。
启动清理任务
启动数据清理任务之前需要先打开TTL表的数据清理开关：
ALTER TABLE `my_ttl_tbl`
MODIFY TTL
SET
TTL_CLEANUP = 'ON';TTL表触发过期数据的清理任务，有以下两种方式：
自动触发：系统按照TTL_JOB定义的调度时间和频次，自动触发过期数据清理任务。
手动触发：手动执行
ALTER CLEANUP EXPIRED DATA触发过期数据清理任务。
TTL_CLEANUP参数设置需实例版本达到polardb-2.5.0_5.4.20-20250328_xcluster5.4.20-20250221或polardb-2.5.0_5.4.20-20250328_xcluster8.4.20-20250304及其以上。早期版本无需设置该参数，默认能进行过期数据清理。因为
TTL_CLEANUP参数默认值为OFF，所以一般情况下需要和TTL_ENABLE参数同时设置为ON，才能顺利完成过期数据的定时清理。
后台自动清理
调整TTL_ENABLE和TTL_CLEANUP为ON，开启定时清理任务：
ALTER TABLE `my_ttl_tbl`
MODIFY TTL
SET
TTL_ENABLE = 'ON',
TTL_CLEANUP = 'ON';开启定时清理任务后，您还可以调整调度任务频率（TTL_JOB）。
手动触发清理任务
后缀ASYNC = TRUE异步执行清理任务：
ALTER TABLE `my_ttl_tbl` CLEANUP EXPIRED DATA ASYNC = TRUE;ALTER TABLE CLEANUP EXPIRED DATA语句仅支持TTL表。系统默认全局最多2张TTL的清理任务同时运行，且每个DN的默认最大清理速度为1000行每秒，越多的DN，清理速度越快，总速度为N*1000Rows/s，其中N为DN数量。您也可以按需调整按行清理的速度限制。
因为清理速度有限，所以TTL_JOB定义的只是预期执行时间，实际执行时需要等待队列前面的任务执行完成。
清理任务默认会将TTL列为NULL值的数据行当做最小值并清理，您可以设置
TTL_FILTER = COND_EXPR( <ttl_col_name> IS NOT NULL ))后，不再自动清理TTL列为NULL值的数据行，该设置仅支持实例版本polardb-2.5.0_5.4.20-20250328_xcluster5.4.20-20250221（MySQL 5.7）及以上或polardb-2.5.0_5.4.20-20250328_xcluster8.4.20-20250304（MySQL 8.0）及以上。
TTL表冷数据清理算法
TTL表有以下两种数据清理策略：
按行清理：通过
DELETE的DML操作完成过期数据清理。按分区清理：通过删除RANGE分区的DDL操作完成过期数据清理。
按行清理
默认采用从前往后逐渐清理的算法，清理过程总是先清理表里最早时间的数据，反复多轮清理后即可动态保留最近一段时间的数据。
按行清理由于使用了DML语句及分布式事务，因此会产生行锁及Binlog日志。每天定时调度的TTL任务为避免在清理数据过程中，产生范围过大行锁或占用过多的CPU/IO资源，系统会自动根据TTL列的最小值计算合适的小范围时间区间并用于清理。
由于按行清理使用DELETE语句清理过期数据时会产生大量Binlog，若应用下游有通过PolarDB-X CDC订阅Binlog的需求，可以在主实例执行如下SQL，以使CDC自动过滤清理过程中产生的DELETE Binlog日志：
SET CDC GLOBAL TASK_EXTRACT_FILTER_ARCHIVE_ENABLED = TRUE;
STOP MASTER;
START MASTER;该SQL需使用高权限账号执行，且仅支持不含普通列存索引的TTL表，切勿在有列存索引的TTL表上执行此SQL。生效后，Binlog将不再生成由TTL表引发的DELETE删除事件。请在确认所有下游系统均不需要同步这些DELETE事件后，再执行此SQL。
清理范围算法
假设有TTL定义TTL_EXPR = `time` EXPIRE AFTER <NUM> MONTH TIMEZONE '+08:00'，则该定义表示TTL表会保留最近NUM个月的数据，那么得出每轮清理任务的上边界如下：
// 清理时间区间的目标上界
CleanupMaxUpperBound = Now - ExpiredDataInterval
// 本轮清理时间区间的上界
CleanupUpperBound = MIN((MinValue + CleanupDataInterval), (Now - ExpiredDataInterval))参数说明：
参数 | 含义 | 详细说明 |
MinValue | TTL时间列的最小值经过时间颗粒调整后产生的值。 | 时间颗粒度调整指的是根据TTL定义的过期时间间隔单位
需要注意的是，当
|
Now | 当前时间经过时间颗粒调整后产生的值。 | |
CleanupDataInterval | 每轮清理数据所涉及的时间范围区间的长度。 | 计算方法为 |
ExpiredDataInterval | TTL表数据的保留时间。 | 例如： |
数据清理示例
示例TTL定义，且假设当前时间为2023-10-01：
CREATE TABLE `tbl` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`time` datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`id`)
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4
PARTITION BY KEY(`id`)
PARTITIONS 8;
ALTER TABLE `tbl`
MODIFY TTL
SET
TTL_EXPR = `time` EXPIRE AFTER 1 MONTH TIMEZONE '+08:00';清理过程如下图所示：
Day 1：
TTL定义的时间列其最小时间值为2022-10-05（MinValue），再根据清理的时间范围（CleanupDataInterval，本例中为3个月）得出本轮清理的范围为2022-10-05≤Time＜2023-01-01。以此类推其他清理范围分别是2023-01-01≤Time＜2023-04-01、2023-04-01≤Time＜2023-07-01、2023-07-01≤Time＜2023-09-01。
Day 2：
同Day 1，清理时间列满足2023-01-01≤Time＜2023-04-01条件的数据，即2023-04-01为本轮清理任务的上边界（CleanupUpperBound）。
Day 3：
同Day 1，清理时间列满足2023-04-01≤Time＜2023-07-01条件的数据，即2023-07-01为本轮清理任务的上边界（CleanupUpperBound）。
Day 4：
与之前略有不同，清理时间列满足2023-07-01≤Time＜2023-09-01条件的数据，时间范围为2个月。因为上图中假设的当前时间为2023-10-01（Now），且TTL表被设置为保留最近1个月（ExpiredDataInterval，TTL表的数据存活时间）的数据，所以本轮只能清理2023-09-01之前的数据，即2023-09-01为本轮清理任务的上边界（CleanupUpperBound）。
按分区清理
对于按分区归档的场景，根据不同的分区过期策略，会采用不同的清理逻辑：
按固定时间间隔过期：TTL任务根据TTL定义所设置数据过期的时间间隔，结合当前最新时间，计算出用于当前清理的目标时间区间，然后扫描所有Range分区，如果分区里的数据完全落在目标时间区间内，则该分区被视为过期分区并被删除。
按固定分区数目过期：TTL任务根据TTL定义所设置保留Range分区数目，从最小的Range分区开始，逐个分区判定过期，直到剩余分区数目刚好等于TTL所指定的保留分区数目。
按固定时间间隔过期示例
创建RANGE分区表
tbl：CREATE TABLE `tbl_range` (`time` DATETIME) PARTITION BY RANGE (`time`) ( PARTITION p20231001 VALUES LESS THAN('2023-10-01'), PARTITION p20231101 VALUES LESS THAN('2023-11-01'), PARTITION p20231201 VALUES LESS THAN('2023-12-01'), PARTITION p20240101 VALUES LESS THAN('2024-01-01') );tbl表指定如下的TTL定义：ALTER TABLE `tbl_range` MODIFY TTL SET TTL_EXPR = `time` EXPIRE AFTER 1 MONTH TIMEZONE '+08:00', TTL_PART_INTERVAL = INTERVAL(1, MONTH), ARCHIVE_TYPE = 'PARTITION';说明tbl的过期时间间隔为1个月，分区间隔为一个月，且是一级分区。清理过程如图所示：
说明如上图所示，当新一轮TTL任务运行时，若当前时间是
2023-12-03, 那么当前时间会按分区间隔单位MONTH先截断为2023-12-01，然后再减去过期时间间隔1个月，最终实际的过期时间点是2023-11-01。所以，分区p20231101与p20231001因其所有数据都满足time < '2023-11-01'的过期条件，它们都会被判定为过期分区并被删除。此外，TTL任务会在正式删除过期分区p20231101与p20231001之前，提前检查并按需自动补充新的Range分区p20240201。
按固定分区数目过期示例
该过期策略通常适用于TTL列为整数类型。
创建按照整数分4个分区的表
tbl：CREATE TABLE `tbl_int` (`uid` BIGINT) PARTITION BY RANGE (`uid`) ( PARTITION p2000000 VALUES LESS THAN(2000000), PARTITION p3000000 VALUES LESS THAN(3000000), PARTITION p4000000 VALUES LESS THAN(4000000), PARTITION p5000000 VALUES LESS THAN(5000000) );tbl的TTL定义：ALTER TABLE `tbl_int` MODIFY TTL SET TTL_EXPR = `uid` EXPIRE OVER 2 PARTITIONS, TTL_PART_INTERVAL = INTERVAL(1000000, NUMBER), ARCHIVE_TYPE = 'PARTITION';说明上述TTL表
tbl的Range分区间隔是一个分区1000000，最多保留2个分区，且按一级分区归档。清理过程如下图所示：
说明如上图所示，
p2000000、p3000000、p4000000与p5000000是TTL表tbl的当前已创建的RANGE分区。当新一轮TTL任务运行时，根据保留的最大分区数目，TTL任务优先从最小的分区p2000000开始数起，逐个分区判定是否过期，直到剩余分区数目为2个（即p4000000与p5000000），从而计算出待清理的过期分区集合（p2000000与p3000000）。之后，TTL任务在正式删除过期分区时，还会先自动补充完新的分区（p6000000），最后将过期分区删除。
查看任务进度
查看TTL表的定义
您可以通过如下代码查询视图INFORMATION_SCHEMA.TTL_INFO，以获取数据库中所有TTL表的定义及其清理任务的调度开关状态：
SELECT *
FROM INFORMATION_SCHEMA.TTL_INFO
WHERE TABLE_SCHEMA=<database_name> AND TABLE_NAME = 'my_ttl_tbl';返回结果：
+--------------+------------+------------+------------+-----------------------------------------------------+-----------------+--------------+----------------------+--------------------+----------------------------+-----------------------------+
| TABLE_SCHEMA | TABLE_NAME | TTL_ENABLE | TTL_COL | TTL_EXPR | TTL_CRON | ARCHIVE_TYPE | ARCHIVE_TABLE_SCHEMA | ARCHIVE_TABLE_NAME | ARCHIVE_TABLE_PRE_ALLOCATE | ARCHIVE_TABLE_POST_ALLOCATE |
+--------------+------------+------------+------------+-----------------------------------------------------+-----------------+--------------+----------------------+--------------------+----------------------------+-----------------------------+
| test_db | my_ttl_tbl | ON | date_field | `date_field` EXPIRE AFTER 1 MONTH TIMEZONE '+08:00' | 0 0 2 */1 * ? * | ROW | test_db | my_ttl_tbl_arc | 3 | 3 |
+--------------+------------+------------+------------+-----------------------------------------------------+-----------------+--------------+----------------------+--------------------+----------------------------+-----------------------------+字段说明：
字段名 | 说明 |
TABLE_SCHEMA | TTL表的逻辑库名。 |
TABLE_NAME | TTL表的逻辑表名。 |
TTL_ENABLE | TTL表是否打开自动清理。 |
TTL_COL | TTL定义的时间列。 |
TTL_EXPR | TTL定义的数据存活时间。 |
TTL_CRON | TTL定时任务的调度间隔的定义。格式为QUARTZ框架的CRON表达式。 |
ARCHIVE_TYPE | 归档类型，取值如下：
|
ARCHIVE_TABLE_SCHEMA | TTL表所对应归档表所在逻辑库名。若该TTL表没有绑定归档表，则该值为NULL。 |
ARCHIVE_TABLE_NAME | TTL表所对应归档表所在逻辑表名。若该TTL表没有绑定归档表，则该值为NULL。 |
ARCHIVE_TABLE_PRE_ALLOCATE | TTL表按照分区规则提前预建的分区数。 |
ARCHIVE_TABLE_POST_ALLOCATE | TTL表已创建的分区数。 |
查看TTL任务状态
您可以通过查询INFORMATION_SCHEMA.TTL_SCHEDULE视图，来获取指定TTL表的清理任务的实时运行信息。
-- 手动调起清理任务
ALTER TABLE `my_ttl_tbl` CLEANUP EXPIRED DATA;
SELECT *
FROM INFORMATION_SCHEMA.TTL_SCHEDULE
WHERE TABLE_SCHEMA = <database_name> AND TABLE_NAME = 'my_ttl_tbl';返回结果：
+--------------+------------+--------------------------------------+---------------------+
| TABLE_SCHEMA | TABLE_NAME | METRIC_KEY | METRIC_VAL |
+--------------+------------+--------------------------------------+---------------------+
| test_db | my_ttl_tbl | SCHEDULE_STATUS | ENABLED |
| test_db | my_ttl_tbl | SCHEDULE_EXPR | 0 0 2 * * ? * |
| test_db | my_ttl_tbl | SCHEDULE_COMMENT | at 02:00 |
| test_db | my_ttl_tbl | SCHEDULE_TIMEZONE | +08:00 |
| test_db | my_ttl_tbl | SCHEDULE_LAST_FIRE_TIME | 1970-01-01 08:00:00 |
| test_db | my_ttl_tbl | SCHEDULE_NEXT_FIRE_TIME | 2025-06-14 02:00:00 |
| test_db | my_ttl_tbl | TTL_CURR_TTL_COL_MIN_VAL | 2025-06-13 17:29:08 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_BOUND | 2025-04-01 00:00:00 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_UPPER_BOUND | 2025-04-01 00:00:00 |
| test_db | my_ttl_tbl | TTL_CURR_NEW_DATETIME_VAL | null |
| test_db | my_ttl_tbl | TTL_CURR_JOB_STAGE | Finished |
| test_db | my_ttl_tbl | TTL_CURR_JOB_BEGIN_TS | 1749807929131 |
| test_db | my_ttl_tbl | TTL_CURR_JOB_END_TS | 1749807931234 |
| test_db | my_ttl_tbl | TTL_CURR_JOB_FROM_SCHEDULER | false |
| test_db | my_ttl_tbl | TTL_CURR_JOB_STOP_BY_MAINTAIN_WINDOW | false |
| test_db | my_ttl_tbl | TTL_CURR_DN_ROWS_SPEED_LIMIT | 1024 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANED_PHY_PART_COUNT | 8 |
| test_db | my_ttl_tbl | TTL_CURR_TOTAL_PHY_PART_COUNT | 8 |
| test_db | my_ttl_tbl | TTL_CURR_JOB_PERCENT | 100 |
| test_db | my_ttl_tbl | TTL_ACQUIRE_PERMITS_AVG_RT_NANO | 11127 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_TIMECOST | 2014 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_ROWS | 0 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_ROWS_SPEED | 0 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_DATA_LENGTH | 0 |
| test_db | my_ttl_tbl | TTL_CURR_CLEANUP_SPEED | 0 |
| test_db | my_ttl_tbl | TTL_CURR_SELECT_SQL_AVG_RT | 8 |
| test_db | my_ttl_tbl | TTL_CURR_DELETE_SQL_AVG_RT | 5 |
| test_db | my_ttl_tbl | TTL_CURR_OPTIMIZE_SQL_AVG_RT | 0 |
| test_db | my_ttl_tbl | TTL_CURR_ADD_PART_AVG_RT | 0 |
| test_db | my_ttl_tbl | TTL_CURR_DROP_PART_AVG_RT | 0 |
| test_db | my_ttl_tbl | TTL_CURR_DATA_FREE_PERCENT_LIMIT | 40 |
| test_db | my_ttl_tbl | TTL_CURR_TTL_TBL_DATA_FREE_PERCENT | 0.00 |
| test_db | my_ttl_tbl | TTL_CURR_OPTIMIZE_TTL_TBL_PROGRESS | 0 |
| test_db | my_ttl_tbl | TTL_LAST_JOB_FROM_SCHEDULER | false |
| test_db | my_ttl_tbl | TTL_LAST_TTL_COL_MIN_VAL | 2025-06-13 17:29:08 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_BOUND | 2025-04-01 00:00:00 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_UPPER_BOUND | 2025-04-01 00:00:00 |
| test_db | my_ttl_tbl | TTL_LAST_JOB_BEGIN_TS | 1749807881814 |
| test_db | my_ttl_tbl | TTL_LAST_JOB_END_TS | 1749807929080 |
| test_db | my_ttl_tbl | TTL_LAST_SELECT_SQL_AVG_RT | 15 |
| test_db | my_ttl_tbl | TTL_LAST_DELETE_SQL_AVG_RT | 8 |
| test_db | my_ttl_tbl | TTL_LAST_OPTIMIZE_SQL_AVG_RT | 0 |
| test_db | my_ttl_tbl | TTL_LAST_ADD_PARTS_SQL_AVG_RT | 0 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_TIMECOST | 2022 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_ROWS | 0 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_ROWS_SPEED | 0 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_DATA_LENGTH | 0 |
| test_db | my_ttl_tbl | TTL_LAST_CLEANUP_SPEED | 0 |
| test_db | my_ttl_tbl | TTL_LAST_TTL_TBL_DATA_FREE_PERCENT | 0.00 |
+--------------+------------+--------------------------------------+---------------------+字段说明：
部分指标名 | 含义 |
SCHEDULE_STATUS | TTL定时任务的调度开关：
|
SCHEDULE_EXPR | TTL定时任务调度时间间隔，该值可以通过调整TTL定义的TTL_JOB表达式进行调整。 |
SCHEDULE_COMMENT | TTL定时任务调度的时间间隔的语义解析。 |
SCHEDULE_TIMEZONE | TTL定时任务调度所用的时区。 |
SCHEDULE_LAST_FIRE_TIME | 上一次触发自动调度的时间值（初始值为 '1970-01-01 08:00:00'， 表示没有触发自动调度）。 |
SCHEDULE_NEXT_FIRE_TIME | 下一次触发自动调度的时间值（初始值为 '1970-01-01 08:00:00'， 表示没有触发自动调度）。 |
TTL_CURR_TTL_COL_MIN_VAL | 当前TTL定时任务的TTL定义的时间列的实时最小值。 |
TTL_CURR_JOB_STAGE | 当前TTL定时任务所处的阶段。 |
TTL_CURR_CLEANUP_BOUND | 当前TTL定时任务的清理范围。 |
TTL_CURR_CLEANUP_UPPER_BOUND | 当前TTL定时任务的清理上界，即本次清理历史数据的范围必须小于该值。 |
TTL_CURR_NEW_DATETIME_VAL | 当前最新的时间。 |
TTL_CURR_DN_ROWS_SPEED_LIMIT | 当前TTL定时任务的清理限速（每个存储节点执行 |
TTL_CURR_CLEANUP_ROWS | 当前TTL定时任务已经清理的总行数。 |
TTL_CURR_CLEANUP_ROWS_SPEED | 当前TTL定时任务的实时清理速度，单位为Row/s。 |
TTL_CURR_CLEANUP_DATA_LENGTH | 当前TTL定时任务已经完成清理的总字节数（估算值）。 |
TTL_CURR_CLEANUP_SPEED | 当前TTL定时任务的实时清理速度，单位为Byte/s（估算值）。 |
TTL_CURR_SELECT_SQL_AVG_RT | 当前TTL定时任务执行 |
TTL_CURR_DELETE_SQL_AVG_RT | 当前TTL定时任务执行 |
TTL_CURR_JOB_PERCENT | 当前TTL定时任务的完成百分比。 |
TTL_CURR_CLEANED_PHY_PART_COUNT | 当前TTL定时任务已完成清理的物理分区数。 |
TTL_CURR_TOTAL_PHY_PART_COUNT | 当前TTL定时任务总共需要完成的物理分区数。 |
管理清理任务
TTL定时清理任务会使用DELETE语句并行地对各个DN进行数据清理，该操作会占用DN的一部分CPU和IOPS资源，您可以通过管理清理任务，使其在合适时间以合适的速度进行数据清理，使清理任务对业务的影响达到最低。
调整可运维时间窗口
PolarDB-X 2.0后台任务默认的可运维窗口是每天02:00 ~ 05:00，您可以通过如下代码将可运维的时间窗口调整至每天01:00 ~ 06:00：
SET GLOBAL MAINTENANCE_TIME_START = '01:00';
SET GLOBAL MAINTENANCE_TIME_END = '06:00';TTL_JOB定义的是TTL任务自动提交的时间点和频率，而可运维窗口MAINTENANCE_TIME_START与MAINTENANCE_TIME_END定义的TTL任务实际被允许执行的时间区间。例如：假设TTL_JOB = CRON '0 0 0 */7 * ? *' TIMEZONE '+08:00'，表示TTL任务每隔7天的0点触发一次提交任务，又假设可运维窗口02:00~05:00（东8区）。那么，TTL任务虽然是在0点被提交的，但实际它会排队等到02:00才能正式开始执行，并且如果TTL任务在05:00时未执行完成，将会自动暂停，等待下次的可运维窗口再执行。
调整按行清理的速度限制
TTL定时清理任务在执行期间，默认会对个DN的清理速度进行限制。该限制是为避免清理任务过度占用DN的CPU和IOPS资源，进而影响在线业务。默认各个DN的清理速度限制是1000Rows/s，即所有TTL表在同一个DN的清理速度的总和最多1000行每秒。越多的DN，清理速度越快，总速度为N*1000Rows/s，其中N为DN数量。
使用如下SQL调整DN的清理速度为每秒10000行：
SET GLOBAL TTL_ENABLE_CLEANUP_ROWS_SPEED_LIMIT=10000;如果DN的CPU或IOPS已满，即使执行上述SQL提高清理速度限制，也不一定能实际提升清理速度。
调整按行的清理时间范围
默认情况下，TTL表的清理任务的时间范围主要是由TTL_CLEANUP_BOUND_INTERVAL_COUNT 参数控制。
调整TTL_CLEANUP_BOUND_INTERVAL_COUNT的值为6，示例如下：
SET GLOBAL TTL_CLEANUP_BOUND_INTERVAL_COUNT = 6;TTL_CLEANUP_BOUND_INTERVAL_COUNT默认值为3，表示3个时间单位。例如：
TTL的时间单位是按天定义：
`time` EXPIRE AFTER num DAY TIMEZONE '+08:00'。默认的清理范围是3 天间隔 ：
[MinValue, MinValue + 3 Day)。TTL的时间单位是按月定义：
`time` EXPIRE AFTER num MONTH TIMEZONE '+08:00'。默认的清理范围是3个月间隔 ：
[MinValue, MinValue + 3 Month)。TTL的时间单位是按年定义：
`time` EXPIRE AFTER num YEAR TIMEZONE '+08:00'。默认的清理范围是3年间隔 ：
[MinValue, MinValue + 3 Year)。
暂停清理任务
通过
SHOW FULL DDL查看所有清理任务的JOB_ID：SHOW FULL DDL\G返回结果
*************************** 1. row *************************** JOB_ID: 1771694362409848832 OBJECT_SCHEMA: ttldb OBJECT_NAME: my_ttl_tbl ENGINE: DAG DDL_TYPE: ALTER_TABLE STATE: RUNNING TOTAL_BACKFILL_PROGRESS: -- CURRENT_PHY_DDL_PROGRESS: 0% PROGRESS: 33% FASTCHECKER_TASK_NUM: 0 FASTCHECKER_TASK_FINISHED: 0 START_TIME: 2024-09-14 15:55:12.991 END_TIME: 2024-09-14 15:55:16.959 ELAPSED_TIME(MS): 3968 PHY_PROCESS: CANCELABLE: true PARENT_JOB_ID: -- RESPONSE_NODE: 10.57.104.154:3067 EXECUTION_NODE: 10.57.104.154:3067 TRACE_ID: 189652a2bc805000 DDL_STMT: alter table my_ttl_tbl cleanup expired data REMARK: -- LEGACY_ENGINE_INFO: --使用第一步得到的
JOB_ID，执行如下代码，即可暂停对应的清理任务：PAUSE DDL 1771694362409848832;
重启清理任务
您可以通过执行如下代码来重启被暂停的清理任务：
CONTINUE DDL 1771694362409848832;