【TiDB 使用环境】生产环境
【TiDB 版本】v8.5.3
【操作系统】arm64
【部署方式】机器部署
配置了 ttl 删除过期时间，一直没生效
有没有大佬知道是什么问题吗？
看贴图语法设置没啥问题，可能TTL规则的过期判断是不是和分区的逻辑一致
如果是数据未超出该分区范围，或分区未开启自动清理机制，TTL不会触发删除
分区怎么开启清理机制，我记得老版本不需要配置这些，只需要按照我上面的配置就行，我这个 tidb 是新创建的，数据是从6.5.9 版本的 tidb 同步过来的，跟我这操作有关系吗？难怪是跟我创建分区的时间有关系？新版本的ttl 特性我不是很了解
TABLE mysql.tidb_ttl_job_history order by create_time desc 查下有ttl记录吗？
有记录，但是所有记录都是 0，“total_rows”:0,“success_rows”:0,
{“total_rows”:0,“success_rows”:0,“error_rows”:0,“total_scan_task”:64,“scheduled_scan_task”:64,“finished_scan_task”:64}
那就是查询下来没有满足条件的数据，你自己select下看看有没有
where条件改成 where start_time <=DATE_SUB( CURRENT_DATE (), INTERVAL 6 MONTH)
另外这个ttl任务查询出来的结果方便截图看看麻
我之前怀疑是表分区没有 analyze导致的，所以我对表分区做了 analyze
通过这个命令查过期数据存在的分区健康度已经是 100 了（之前是 0）
SHOW STATS_HEALTHY WHERE db_name = ’ xxx’ AND table_name = ‘xxx’;
结果过了 2 个小时，ttl 还是没生效
慢sql里面有下面这种sql吗？捞出来执行下看看结果
SELECT
LOW_PRIORITY SQL_NO_CACHE id
FROM
xxx
WHERE
id >= xxx
AND id < xxx
AND create_time < FROM_UNIXTIME(xxx)
ORDER BY
id ASC
LIMIT
500;
这里能看到一个问题，就是 stop_time，我们之前的 ttl 列是 start_time，在老的 tidb（v6.5.9）中是可以的，昨天在新的tidb 集群（v8.5.3）中，ttl没生效，所以改成了 start_time，重启了 ttl 开关，也还是没生效
ALTER TABLE t1 REMOVE TTL; remove掉重新设置试试呢
这个也试过了，也是不行
你这也太奇怪了，我之前设置是立刻生效的。
不知道是不是 8.5.3 的 bug，我3 个集群 v6.5.9，v8.1.1 都生效了，就是这个新版的不生效
1 个赞
确认了，不是版本问题，删除过了好几天才进行，因为现在的版本是按分区去删的，我们是按天分区，每一天的分区数据比较多，关扫描都要花很长时间，而且不是逆序扫描，感觉像是随机扫描