TiDB 长事务会带来哪些风险，生产环境该如何管控长事务？

🪐 TiDB 技术问题
1

【TiDB 使用环境】生产
【TiDB 版本】v8.0.0
【问题描述】
业务存在部分运行时间很长的事务，想了解长事务会给 TiDB 集群带来哪些具体风险。同时咨询生产环境下，有哪些参数、监控、业务改造手段，用来识别、限制、管控长事务，规避集群故障。

【期望得到的帮助】

  1. 长事务对 GC、MVCC、内存、锁、Raft 副本的影响
  2. 生产可用的管控配置与最佳实践
  3. 如何快速定位是谁产生了长事务
2

长事务在生产上确实是个头疼的问题，我直接给你说重点：

风险影响

  • GC 被阻塞，历史版本堆积，导致存储空间膨胀和查询变慢
  • 事务内修改的行数越多，内存和锁开销越大，容易触发 OOM 或锁等待超时
  • Raft 日志同步压力增大，可能影响集群整体延迟

管控配置

  • 设置 tidb_gc_life_time 默认 10m，配合 tidb_gc_max_wait_time 控制 GC 等待
  • 开启 tidb_enable_async_commit 和 tidb_enable_1pc 减少两阶段提交开销
  • 用 tidb_mem_quota_query 限制单事务内存，超限自动取消
  • 建议开启 tidb_server_memory_limit 防止 OOM

定位长事务

  • 查 information_schema.tidb_trx 表，过滤 STATE='Running' 且时间长的
  • 看监控面板 TiDB Dashboard 的“事务”页，按持续时间排序
  • 慢日志里搜 prewrite 耗时长的 SQL，配合 tidb_slow_log_threshold 调低阈值

业务改造

  • 大事务拆小，按批次提交
  • 避免在事务里做 RPC 调用或长时间等待
  • 用乐观锁模式，减少锁持有时间

先按这个排查，有问题再贴具体监控截图。

3

长事务会挡住 GC、堆 MVCC、占内存和锁，严重时拖复制。用 INFORMATION_SCHEMA.TIDB_TRX / 慢日志找超长事务，设 tidb_max_txn_ttl 并监控 lock wait。业务拆批、尽快提交；分析类查询不要包在大事务里。

1 个赞
4

oracle 对于大事务，或者长事务，也会有相同的问题，这些经验一样可以借鉴

5

设置 tidb_gc_life_time 默认 10m，配合 tidb_gc_max_wait_time 控制 GC 等待

6

长事务风险

  1. 占用 MVCC 版本，造成版本堆积，Region 扫描变慢，CPU、内存上涨。
  2. 锁持有时间久，容易锁冲突、死锁，阻塞业务 DML。
  3. 阻碍 GC，旧快照无法回收，存储空间膨胀。
  4. 事务未提交会占用乐观锁的事务 ID，影响全局 TSO 推进。

生产管控手段

  1. 设置 tidb_max_transaction_size、tidb_long_trx_threshold 告警阈值，监控告警长事务。
  2. 开启 tidb_gc_life_time 合理 GC 窗口，避免过大。
  3. 业务拆分大事务，拆成分批小事务；禁止业务交互式长事务。
  4. 系统变量 tidb_max_execution_time 限制 SQL 执行时长。
  5. 监控 information_schema.tidb_trx，及时发现并 kill 异常长事务。
1 个赞
7

对大事务进行监控，然后拆成分批小事务

8

配置脚本，把定期kill长事务。

9

直接KILL感觉有风险呀

10

部分场景，确定可以这么做的，不能是全局的。

11

长事务会引发 MVCC 垃圾堆积、OOM 等集群风险，生产上应通过设置 max-execution-time / tidb_mem_quota_query 等参数硬性限流。