YugabyteDB中事务性DDL操作导致Schema版本异常问题分析

问题现象

在YugabyteDB 2.25.2.0-b272版本中，发现一个关于事务性DDL操作的特殊问题：当DDL(数据定义语言)和DML(数据操纵语言)混合在同一个事务中时，即使事务最终被回滚，表的Schema版本号仍然会被递增。这会导致并发查询因Schema版本不匹配而失败。

问题复现步骤

1. 首先创建一个测试表t2
2. 开启两个会话(Session)
3. 在Session 1中：
   • 开始事务
   • 执行ALTER TABLE添加列
   • 执行INSERT语句插入数据
   • 最后回滚事务
4. 在Session 2中：
   • 开始事务
   • 在Session 1执行过程中尝试查询表t2
5. 结果：Session 2会收到Schema版本不匹配的错误

值得注意的是，如果事务中不包含DML操作(即去掉INSERT语句)，这个问题就不会出现。

技术背景

YugabyteDB是一个分布式SQL数据库，支持PostgreSQL协议。在传统数据库中，DDL操作通常是自动提交的，而YugabyteDB通过引入事务性DDL特性，允许DDL和DML在同一个事务中执行。

Schema版本控制是数据库系统中的重要机制，用于跟踪表结构的变化。当表结构发生变化时，版本号会递增，以确保所有会话都能感知到最新的表结构。

问题根源分析

从现象来看，问题出现在DDL和DML混合的事务场景中。具体表现为：

1. Schema版本提前递增：即使事务回滚，Schema版本号仍然被递增，这违反了事务的原子性原则。
2. DML操作的关键作用：问题仅在事务中包含DML操作时出现，表明DML操作可能触发了某种机制，导致Schema版本变更被"固化"。
3. 并发控制失效：由于Schema版本异常递增，其他会话在查询时会检测到版本不匹配，导致查询失败。

影响范围

这个问题会影响以下场景：

• 使用事务性DDL特性的应用
• 在同一个事务中混合执行DDL和DML操作
• 高并发环境下对同一表的访问

解决方案建议

虽然这是一个已确认的bug，但在修复前可以考虑以下临时解决方案：

1. 避免混合DDL和DML：在事务中只执行DDL或只执行DML操作
2. 分离DDL事务：将DDL操作放在单独的事务中执行
3. 重试机制：应用层捕获Schema版本不匹配错误并重试查询

技术启示

这个问题揭示了分布式数据库中实现事务性DDL的复杂性。在传统单机数据库中，Schema变更通常通过锁机制来保证一致性，而在分布式环境中，需要协调多个节点对Schema变更的认知，这增加了实现的难度。

对于数据库开发者而言，这个问题提醒我们需要特别注意：

• 事务性操作的原子性保证
• Schema版本管理的正确性
• DDL和DML操作的交互影响

总结

YugabyteDB中事务性DDL与DML混合操作导致的Schema版本异常问题，展示了分布式数据库在实现高级特性时面临的挑战。理解这一问题的表现和根源，有助于开发者在实际应用中规避类似问题，同时也为数据库内核开发者提供了有价值的调试案例。