游戏卡顿白皮书 › L12 数据库
长事务 Long-running transaction / MVCC purge lag
原因 ID db-long-tx · 主责 研发团队·服务器开发 · 配合 运维团队·数据库运维
在含图示和实验的完整版中打开此卡片 →
一个事务长时间不结束，就会一直持有锁，DB 也没法清理（purge）旧版本数据，整体逐渐变慢。
起因 开着事务去等其他服务器的响应，或运营期间在主库上跑长时间的统计查询 → 结果 持有的锁不释放，待清理的旧版本数据不断堆积 → 画面表现 用到这些行的功能超时，几个小时内存盘、查询普遍变慢
症状 操作延迟 , 吞操作/回档 因素 延迟, 停顿
谁会遇到 仅特定功能, 全服
何时出现 开得越久越严重, 偶尔随机
负责方 主责 研发团队·服务器开发 · 配合 运维团队·数据库运维
研发团队要做的事 不要在事务里等待网络调用或用户输入，统计查询放到从库上。
运维团队要做的事 对长事务告警并强制终止，提供统计专用从库，监控 undo log 和死元组的增长。
监控图上 查看位置 MySQL 用 INFORMATION_SCHEMA.INNODB_TRX 的 trx_started 找出最老的事务，看 SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分中的 History list length（尚未清理的 undo log 量）。PostgreSQL 看 pg_stat_activity 的 xact_start 和 state 为 idle in transaction 的会话，以及 pg_stat_user_tables 的 n_dead_tup 确认依据 存在已持续几分钟到几小时的事务，期间 History list length 或 n_dead_tup 持续上升；结束这个事务后，随着清理（purge、VACUUM）运行而下降 排除依据 没有长事务却普遍变慢，看“检查点/日志刷盘”（db-checkpoint）或磁盘问题 确认手段 运维工具即可确认（无需游戏代码）
深入了解 为了让读的一方能看到修改之前的样子，DB 会保留旧版本（MVCC）。最老的事务结束后这些记录才能删除，所以一个事务开着几个小时，MySQL 会堆积 undo log，PostgreSQL 会堆积 VACUUM 清理不掉的死元组（dead tuple）。SQL Server 则会因事务日志无法收缩而把磁盘占满。
出处 InnoDB Multi-Versioning MySQL 只要还有能看到旧版本的事务，update undo log 就无法丢弃，回滚段会变大；建议只读事务也要经常提交 Routine Vacuuming (PostgreSQL Documentation) PostgreSQL 旧的行版本在其他事务还能看到时无法删除；长事务需要结束，或终止其会话 Client Connection Defaults (PostgreSQL Documentation) PostgreSQL idle_in_transaction_session_timeout：断开开着事务却处于空闲的会话，避免其长时间持锁 Troubleshoot a full transaction log (SQL Server Error 9002) Microsoft SQL Server 长时间运行的活动事务会阻碍事务日志清理 The INFORMATION_SCHEMA INNODB_TRX Table MySQL TRX_STARTED：事务开始时间 Purge Configuration MySQL 已提交事务的 undo log 列表（history list）由 purge 清理，积压量显示在 SHOW ENGINE INNODB STATUS 的 TRANSACTIONS 部分的 History list length 中 The Cumulative Statistics System (PostgreSQL Documentation) PostgreSQL pg_stat_activity 的 xact_start（事务开始时间）和 state（idle in transaction），pg_stat_user_tables 的 n_dead_tup（死元组估计数） 相关原因
同一层：L12 数据库
其他层中同样导致“操作延迟”的原因
查看含图示和实验的原卡片