事务与锁是关系型数据库的核心机制也是理解并发控制的基础。本文整理 GaussDB 中事务管理、MVCC 元组可见性、表级锁分级以及死锁检测相关的知识点。一、事务基础GaussDB 支持显式事务和隐式事务隐式事务单条语句自动提交不需要手工COMMIT。显式事务通过BEGIN/START TRANSACTION开启COMMIT/END提交。关于嵌套事务有一个常见的错误认知所谓嵌套事务可以独立于外部事务进行提交或回滚是错误的。实际上在正常事务块中再次执行开启事务的命令时系统会提示已有事务正在进行并忽略新的开启命令。需要区分的是SAVEPOINT建立的子事务机制并不等于一个能脱离外部事务独立提交的顶层事务。子事务的回滚只回退事务内的修改不会倒退存储过程的执行流程或局部变量。二、MVCC 与元组可见性MVCC多版本并发控制的核心思想是写事务不立即修改元组而是创建新版本并保留旧版本UPDATE本质上等价于DELETE INSERT。一个元组版本的可见性由两个字段决定xmin创建该元组版本的事务 ID。xmax删除或更新该元组版本的事务 ID。当前查询能否看到某条记录取决于这两个字段的组合xminxmax记录是否可见可见不可见可见可见可见不可见已删除或被更新不可见可见不可见不可见不可见不可能组合最核心的一条结论xmin 可见、xmax 不可见时记录对当前查询可见。直观理解就是——插入已经生效而删除或更新尚未对当前快照生效。三、八级表锁GaussDB 的表级锁分为 8 个级别从轻到重依次是级别锁模式典型语句或用途1ACCESS SHARESELECT2ROW SHARESELECT FOR UPDATE/SHARE3ROW EXCLUSIVEINSERT/UPDATE/DELETE4SHARE UPDATE EXCLUSIVEVACUUM、ANALYZE、CREATE INDEX CONCURRENTLY5SHARECREATE INDEX6SHARE ROW EXCLUSIVE类似 7 级锁但允许 2 级锁并发7EXCLUSIVE事务锁、扩展锁仅允许普通查询并发8ACCESS EXCLUSIVEDDL、VACUUM FULL、LOCK TABLE默认锁冲突判断的常用规则两个锁的级别之和大于等于 8 时通常会发生冲突。一个重要的特例是5 级锁与 5 级锁不冲突即两个CREATE INDEX可以并发执行。另外ROW SHARE2 级与EXCLUSIVE7 级、ACCESS EXCLUSIVE8 级是冲突的。四、死锁检测deadlock_timeout参数用于控制死锁检测的启动时机单位为毫秒默认值为1 秒。只有当锁等待达到这个时间后数据库才会启动死锁检查。也就是说数据库不会在每次发生锁等待时立即执行死锁检查而是要等锁等待持续一段时间后才开始检测这是为了避免频繁的无效检查。调大这个参数可以减少无效的死锁检查但代价是真正的死锁会被报告得更慢配合log_lock_waits调查锁等待时可以临时把它设得比正常值小。五、分布式事务在分布式架构下跨分片的事务需要全局协调GTM全局事务管理器负责分配全局事务 ID、全局快照、时间戳和 sequence。两阶段提交2PC阶段一prepare所有提交所需的信息和资源持久化到磁盘DN 置为 commit-in-progress。阶段二commitCN 通知 GTM 提交并获取全局唯一 CSN再向所有 DN 发 commit。2PC 的原子性关键在于prepare 成功后信息已经持久化因此提交阶段即使部分节点出错也可以补偿重试直至最终完成提交。在一致性模型上需要区分两种模式GTM-Lite仍保证强一致性不等同于最终一致。GTM-Free减少对 GTM 的依赖偏向最终一致和高性能适合互联网完美 sharding 场景。小结嵌套事务不能独立于外部事务提交/回滚。MVCC 可见性看xmin 可见 xmax 不可见。八级表锁按查、锁定查、增删改、维护、索引、强共享行、排他、DDL记忆级别之和 ≥8 冲突特例 55 不冲突。deadlock_timeout默认 1 秒控制死锁检测启动时机。分布式用 2PC 保证原子性GTM-Lite 强一致、GTM-Free 偏最终一致。
