TiDB 无法删除某一行数据，提示 commit_ts_expired 错误

🪐 TiDB 技术问题
1

我们目前遇到的问题是在生产环境的 3 节点集群（使用 TiDB、TiKV、PD 版本 8.5.1）中，无法删除一条特定的数据行。

执行语句：

> delete from records where id = 3991874453;
ERROR 1105 (HY000): unexpected resolve err: commit_ts_expired:<start_ts:455172192182209523 attempted_commit_ts:455172192182210339 key:"t\200\000\000\000\000\000\000r_i\200\000\000\000\000\000\000\003\000\003\200\000\000\000\355\357+\225" min_commit_ts:455172192785137665 > , lock: key: 7480000000000000725f698000000000000003000380000000edef2b95, primary: 7480000000000000725f7280000000edef2b20, txnStartTS: 455172192182209523, lockForUpdateTS:455172192182209837, minCommitTs:455172192785137665, ttl: 3857, type: Put, UseAsyncCommit

看起来这个操作被某个事务阻塞了（但在 information_schema.data_lock_waits 中看不到该事务的信息）。根据 SELECT TIDB_PARSE_TSO(455172192182209523); 的结果，这个事务从 1 月 8 日 就存在了。

我尝试过以下操作：
• 在所有节点上执行了 tikv-ctl compact -c {write, lock, default} --bottommost force，所有 compact 操作都成功完成；
• 针对所有 Region 执行了 tikv-ctl consistency-check（通过 select region_id from tikv_region_peers where is_leader = 1 and store_id = {current_node_store_id} 获取 Region ID），检查结果也都通过。

但这些操作都没有解决问题。

如果有任何关于如何删除该行的建议我将不胜感激。比如，是否有办法可以直接列出 TiKV 中的锁（甚至更新它们）？这样做是否安全？

1 个赞
2

SELECT * FROM information_schema.cluster_tidb_trx;这个表里有锁吗？

3

感觉这是提交超时了

4

大佬，这个表好像只显示当前活跃事务

> SELECT START_TIME FROM information_schema.cluster_tidb_trx;
+----------------------------+
| START_TIME                 |
+----------------------------+
| 2025-04-23 12:30:58.952000 |
| 2025-04-23 12:30:58.903000 |
| 2025-04-23 12:30:58.903000 |
| 2025-04-23 12:30:58.802000 |
| 2025-04-23 12:30:58.903000 |
| 2025-04-23 12:30:58.802000 |
| 2025-04-23 12:30:57.802000 |
| 2025-04-23 12:30:58.602000 |
| 2025-04-23 12:30:58.602000 |
| 2025-04-23 12:30:55.802000 |
| 2025-04-23 12:30:51.702000 |
| 2025-04-23 12:30:57.002000 |
| 2025-04-23 12:30:58.702000 |
| 2025-04-23 12:30:58.952000 |
| 2025-04-23 12:30:52.303000 |
| 2025-04-23 12:30:58.303000 |
| 2025-04-23 12:30:55.452000 |
| 2025-04-23 12:30:55.652000 |
| 2025-04-23 12:30:53.352000 |
| 2025-04-23 12:30:57.102000 |
| 2025-04-23 12:30:57.703000 |
| 2025-04-23 12:30:56.252000 |
| 2025-04-23 12:30:58.752000 |
| 2025-04-23 12:30:55.902000 |
| 2025-04-23 12:30:58.852000 |
| 2025-04-23 12:30:57.102000 |
| 2025-04-23 12:30:58.752000 |
+----------------------------+
27 rows in set (0.069 sec)
5

select TIDB_PARSE_TSO(455172192182209523) – start_ts: 2025-01-08 13:48:36.906000

select TIDB_PARSE_TSO(455172192182210339) – attempted_commit_ts: 2025-01-08 13:48:36.906000

select TIDB_PARSE_TSO(455172192785137665) – min_commit_ts:2025-01-08 13:48:39.206000

select TIDB_PARSE_TSO(455172192182209523) – txnStartTS:2025-01-08 13:48:36.906000

select TIDB_PARSE_TSO(455172192182209837) – lockForUpdateTS:2025-01-08 13:48:36.906000

尝试解析了一下这几个tso，确实令人费解，都是1月8号的。