修改 tidb_max_txn_ttl 参数可以限制事务的最大存活时间，防止长事务持有锁过久影响 GC 和 schema 变更，适用于存在长事务阻塞集群的场景。调整 tidb_max_txn_ttl 参数不会阻止大事务产生，但会在事务超时时强制回滚，风险是可能误杀合法的长耗时业务。
先说结论：调整 tidb_max_txn_ttl 参数是保护集群稳定性的兜底手段，而非优化大事务的根本方案。
- 适合：集群出现因长事务导致的 GC 延迟或锁等待报警
- 先准备：评估业务最大合理事务耗时，避免设置过小
- 验收：监控事务错误日志及锁等待情况
命令速用版
SET GLOBAL tidb_max_txn_ttl = 3600000;SET GLOBAL 命令将最大事务 TTL 设置为 3600000 毫秒（1 小时），执行后立即生效，无需重启集群。
为什么会这样
tidb_max_txn_ttl 参数用于定义事务允许持有的最大锁时间，超过该阈值的事务会被锁 resolver 清理。
TiDB 事务基于 MVCC 和锁机制，长事务会阻碍 GC 回收旧版本数据并占用锁资源。设置 tidb_max_txn_ttl 参数是为了防止异常长事务无限期持有锁，导致集群无法推进 GC 或阻塞 DDL 操作。修改 tidb_max_txn_ttl 参数只是设定了上限，并不能优化事务本身的执行效率。
分步处理
第一步：确认当前参数值。
SHOW VARIABLES LIKE 'tidb_max_txn_ttl';第二步：评估业务需求。
检查业务逻辑中是否存在必须超过默认值的长耗时操作，如大批量数据导入或复杂报表生成。公开资料中没有看到可靠的量化数据表明具体业务应设置的具体数值，需根据实际业务耗时峰值决定。
第三步：修改全局参数。
SET GLOBAL tidb_max_txn_ttl = <目标毫秒数>;第四步：持久化配置（可选）。
若需重启后生效，需在 TiDB 配置文件 tidb.toml 或 PD 配置中同步修改，具体取决于集群管理方式。
怎么验证是否生效
执行查询命令确认新值，并观察慢事务日志。
SHOW VARIABLES LIKE 'tidb_max_txn_ttl';检查 TiDB 日志中是否有事务因 TTL 超时被回滚的记录，确认业务侧是否收到事务超时错误。
常见坑
- 设置过小会导致正常长业务失败，引发应用层报错。
- tidb_max_txn_ttl 参数不能解决慢 SQL 问题，根本方案仍是优化索引和事务粒度。
- 修改后仅对新事务生效，已运行的长事务不受影响直到结束或被清理。
常见问题
修改后 existing 事务会立即中断吗
不会立即中断，tidb_max_txn_ttl 参数主要限制新事务的最大存活时间，已运行事务由锁 resolver 根据旧规则或新规则逐步清理。
默认值是多少
默认值通常为 3600000 毫秒，即 1 小时，具体版本请以官方文档为准。
参考来源
- PingCAP TiDB 官方文档 - 系统变量 tidb_max_txn_ttl
- https://docs.pingcap.com/zh/tidb/stable/system-variable-tidb-max-txn-ttl