GBase 8a 事务隔离级别与读写一致性：配置边界与现场验证

分布式 MPP 数据库的事务语义由协调节点会话管理、锁机制与多版本可见性规则共同决定。GBase 8a 在语法上兼容常见 SQL 事务接口（START TRANSACTION、COMMIT、ROLLBACK、SET SESSION TRANSACTION ISOLATION LEVEL 等，以版本文档为准），但在多 DataNode 参与同一语句执行时，隔离级别对锁持有时间、幻读风险、以及只读报表一致性的影响 与单机实例存在差异。本文从 DBA 可操作的配置与验证出发，说明各级别的行为边界、与长事务/锁等待的关联，以及批处理与在线交易共存时的建议。不涉及应用框架事务传播细节。

一、隔离级别与异常现象对照

SQL 标准定义四类隔离级别，实际产品对各异常的禁止程度以实现为准。现场排障时，将业务现象映射到下表，再核对会话隔离级别与事务边界。

隔离级别	脏读	不可重复读	幻读	典型会话配置
READ UNCOMMITTED	可能	可能	可能	极少在生产使用
READ COMMITTED	禁止	可能	可能	多数 OLTP 默认候选
REPEATABLE READ	禁止	禁止	可能	报表、对账场景
SERIALIZABLE	禁止	禁止	禁止	强一致短事务

在 8a 上，级别越高通常意味着 锁范围扩大或持有时间延长，与 SHOW PROCESSLIST 中 Locked 状态、元数据锁等待的相关性上升。升级隔离级别不能替代分布键设计与 SQL 优化，但可降低并发下的逻辑不一致投诉。

二、会话级设置与生效范围

隔离级别一般在会话级设置，影响该连接后续开启的事务（语法以文档为准）：

SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED;
START TRANSACTION;
-- DML / SELECT
COMMIT;

注意点：

1. 连接池：池化连接可能复用上一会话的级别；应用应在取连接后显式设置，或在池配置中统一初始化 SQL。
2. 只读事务：部分版本支持 START TRANSACTION READ ONLY，用于报表路由到只读 CN（若架构支持）；只读仍可能持有元数据锁，取决于访问对象与 DDL 并发。
3. 自动提交：autocommit=1 时每条语句为独立事务，隔离级别仍影响单语句内的读视图，但不存在跨语句的不可重复读（除非显式事务块）。

变更隔离级别后，应对核心业务 SQL 做 并发回归：两会话交错读写，验证是否符合预期。

三、读已提交（READ COMMITTED）现场特征

READ COMMITTED 下，同一事务内两次相同 SELECT 可能读到不同结果（他事务已提交）。在 8a MPP 场景中：

• 扫描大表时，其他会话的并发 INSERT/DELETE 可能导致第二次读取行数变化（幻读类现象）。
• 若语句触发跨节点 REDISTRIBUTE，执行时间较长，窗口内并发提交越多，不一致窗口越大。

适用：短事务 OLTP、对单行或短范围更新一致性要求高、可接受报表轻微波动的查询。

不适用：同一事务内依赖「多次读取结果不变」的库存核对、余额累加校验（应提高隔离级别或改用 SELECT ... FOR UPDATE 等显式锁定，以版本支持为准）。

四、可重复读（REPEATABLE READ）与锁等待

REPEATABLE READ 通过一致性读视图与锁策略减少不可重复读。副作用：

1. 间隙锁或范围锁（若实现）：并发插入可能阻塞。
2. 长事务：从 information_schema.innodb_trx 或等价视图查看 trx_started，持有旧视图会阻碍 vacuum/统计信息类维护（名称以版本为准）。
3. 死锁：多表按不同顺序更新时，死锁概率上升；需从 SHOW ENGINE INNODB STATUS 或集群死锁日志定位（以版本为准）。

批处理任务若使用 REPEATABLE READ 扫描亿级表，极易与在线 UPDATE 形成锁链。建议批任务使用 独立账号、维护窗口、较低并发，或改为分片键范围分批提交。

五、串行化（SERIALIZABLE）使用约束

SERIALIZABLE 提供最强隔离，代价是吞吐下降与锁冲突增加。在 8a 上仅建议用于：

• 短小的关键账务事务（行级更新、明确主键范围）；
• 明确禁止并发写入的割接脚本（仍须控制执行时间）。

禁止在 SERIALIZABLE 下对多张大表做无索引全表扫描更新；计划差与锁持有叠加后，故障表现为全集群 Locked 蔓延（参见锁等待专题）。

六、只读查询与一致性读

只读 SELECT 在默认级别下通常不阻塞他事务写入（除元数据锁冲突）。但下列情况会导致「读到中间态」或报错：

情况	表现	处理
长事务未提交阻塞 DDL	DDL 等待或超时	终止长事务或错峰 DDL
大批量 DML 与报表并发	行数波动、偶发锁等待	报表提高隔离或固定快照点（若支持）
统计信息过旧	计划抖动，非隔离问题	ANALYZE 后重试

若产品支持 一致性快照导出 或 只读副本 CN，报表类 workload 应路由到专用入口，避免与写入争抢同一 CN 连接与锁资源。

七、与 MPP 执行计划的交叉影响

隔离级别不改变 Motion 算子类型，但影响 语句执行墙钟时间，从而放大并发冲突概率：

1. 高隔离 + 大 REDISTRIBUTE → 事务时间拉长 → 锁冲突窗口增大。
2. 同一事务内多次扫描大表 → 多次获取一致性视图 → CPU/IO 重复消耗。

因此性能优化与事务配置应联合评审：在 EXPLAIN 合理后，再评估隔离级别是否可维持；若计划含全分片扫，优先缩范围或改分布键，而非仅提高隔离级别。

八、现场验证步骤

1. 在测试库创建会话 A、B，统一设置待验证隔离级别。
2. A START TRANSACTION；B START TRANSACTION。
3. 按用例表执行交错 SELECT/INSERT/UPDATE/COMMIT，记录每次读取行数与关键列值。
4. 对核心业务表重复用例 3，包含 Join 与 GROUP BY 报表 SQL。
5. 在生产低峰用只读账号抽样：查询 @@transaction_isolation（变量名以版本为准）与连接池默认配置是否一致。
6. 结合 SHOW PROCESSLIST 观察锁等待是否与特定隔离级别+SQL 组合相关。
7. 将确认的配置写入发布清单：应用版本、池参数、初始化 SQL。

九、运维规范建议

1. 默认级别文档化：全公司连接池默认 READ COMMITTED 或现场选定值，禁止实例级随意修改。
2. 批处理账号分离：批任务不得与在线交易共用高隔离长事务配置。
3. 超时：设置 innodb_lock_wait_timeout 或等价参数与语句超时，避免无限等待（参数以文档为准）。
4. 监控：长事务数、锁等待时长、死锁计数纳入告警；与连接数告警并列。
5. 变更评审：提高隔离级别或扩大事务范围前，必须附带 EXPLAIN 与预估行数。

十、案例说明

场景：对账任务在默认 READ COMMITTED 下，同一事务两次汇总 SUM(amt) 结果相差一笔；原因为第二次读取前，另一会话已提交补充入账。

调整：对账会话改为 REPEATABLE READ，并将汇总范围缩小到 WHERE biz_date = ? 单日分区；对账 SQL EXPLAIN 确认分区裁剪生效。

结果：同一事务内两次汇总一致；对账窗口缩短，锁持有时间可控。若对账仍跨多日，应分日事务提交，避免单事务覆盖过大时间范围。

小结

GBase 8a 事务隔离级别的选型需同时考虑 逻辑一致性要求、事务持续时间、MPP 计划代价 三项。READ COMMITTED 适合短 OLTP；REPEATABLE READ 用于同事务内读一致但须控制范围与时长；SERIALIZABLE 仅用于短临界区。实施上以会话配置+连接池初始化为入口，用交错测试用例验证，并结合 PROCESSLIST、长事务视图做运行期监控。配置变更与验证结果应写入运维基线，避免仅依赖应用侧「默认行为」。