GaussDB 事务与锁机制：MVCC 可见性、八级表锁与死锁检测

事务与锁是关系型数据库的核心机制，也是理解并发控制的基础。本文整理 GaussDB 中事务管理、MVCC 元组可见性、表级锁分级以及死锁检测相关的知识点。

一、事务基础

GaussDB 支持显式事务和隐式事务：

• 隐式事务：单条语句自动提交，不需要手工COMMIT。
• 显式事务：通过BEGIN/START TRANSACTION开启，COMMIT/END提交。

关于嵌套事务有一个常见的错误认知：所谓"嵌套事务可以独立于外部事务进行提交或回滚"是错误的。实际上，在正常事务块中再次执行开启事务的命令时，系统会提示已有事务正在进行，并忽略新的开启命令。

需要区分的是：SAVEPOINT建立的子事务机制，并不等于一个能脱离外部事务独立提交的顶层事务。子事务的回滚只回退事务内的修改，不会倒退存储过程的执行流程或局部变量。

二、MVCC 与元组可见性

MVCC（多版本并发控制）的核心思想是：写事务不立即修改元组，而是创建新版本并保留旧版本，UPDATE本质上等价于DELETE + INSERT。

一个元组版本的可见性由两个字段决定：

• xmin：创建该元组版本的事务 ID。
• xmax：删除或更新该元组版本的事务 ID。

当前查询能否看到某条记录，取决于这两个字段的组合：

最核心的一条结论：xmin 可见、xmax 不可见时，记录对当前查询可见。直观理解就是——插入已经生效，而删除或更新尚未对当前快照生效。

三、八级表锁

GaussDB 的表级锁分为 8 个级别，从轻到重依次是：

冲突判断的常用规则：两个锁的级别之和大于等于 8 时，通常会发生冲突。

一个重要的特例是：5 级锁与 5 级锁不冲突（即两个CREATE INDEX可以并发执行）。

另外，ROW SHARE（2 级）与EXCLUSIVE（7 级）、ACCESS EXCLUSIVE（8 级）是冲突的。

四、死锁检测

deadlock_timeout参数用于控制死锁检测的启动时机：

• 单位为毫秒，默认值为1 秒。
• 只有当锁等待达到这个时间后，数据库才会启动死锁检查。

也就是说，数据库不会在每次发生锁等待时立即执行死锁检查，而是要等锁等待持续一段时间后才开始检测，这是为了避免频繁的无效检查。

调大这个参数可以减少无效的死锁检查，但代价是真正的死锁会被报告得更慢；配合log_lock_waits调查锁等待时，可以临时把它设得比正常值小。

五、分布式事务

在分布式架构下，跨分片的事务需要全局协调：

• GTM（全局事务管理器）负责分配全局事务 ID、全局快照、时间戳和 sequence。
• 两阶段提交（2PC）：
  • 阶段一prepare：所有提交所需的信息和资源持久化到磁盘，DN 置为 commit-in-progress。
  • 阶段二commit：CN 通知 GTM 提交并获取全局唯一 CSN，再向所有 DN 发 commit。

2PC 的原子性关键在于：prepare 成功后信息已经持久化，因此提交阶段即使部分节点出错，也可以补偿重试直至最终完成提交。

在一致性模型上，需要区分两种模式：

• GTM-Lite：仍保证强一致性，不等同于最终一致。
• GTM-Free：减少对 GTM 的依赖，偏向最终一致和高性能，适合互联网完美 sharding 场景。

小结

• 嵌套事务不能独立于外部事务提交/回滚。
• MVCC 可见性看xmin 可见 + xmax 不可见。
• 八级表锁按"查、锁定查、增删改、维护、索引、强共享行、排他、DDL"记忆，级别之和 ≥8 冲突，特例 5+5 不冲突。
• deadlock_timeout默认 1 秒，控制死锁检测启动时机。
• 分布式用 2PC 保证原子性，GTM-Lite 强一致、GTM-Free 偏最终一致。