MySQL中DDL不支持事务。
- 传统MySQL（5.7及以前版本）：
- DDL操作不支持事务
- 执行DDL操作时会隐式提交当前会话的事务
- 无法回滚DDL操作
- MySQL 8.0版本：
- 引入了原子DDL特性（Atomic DDL）
- DDL操作变为原子性的，要么全部成功，要么全部失败
- 但这并不意味着DDL操作可以和普通DML操作放在同一个事务中
- DDL操作仍然会导致前面的事务隐式提交
举例说明：
START TRANSACTION;
INSERT INTO users (name) VALUES ('Alice'); -- DML操作ALTER TABLE users ADD COLUMN age INT; -- DDL操作-- 这里会自动提交前面的INSERT操作-- ALTER TABLE是原子性的INSERT INTO users (name, age) VALUES ('Bob', 25); -- 新的事务开始
COMMIT;
需要注意的要点：
- DDL操作会自动提交之前的事务
- DDL操作本身具有原子性（在MySQL 8.0中）
- 不能在一个事务中混合DDL和DML操作并期望它们一起回滚
原因
MySQL中DDL不支持事务的主要原因有以下几点：
- 元数据锁定机制
- DDL操作需要修改数据库的元数据（表结构、索引等）
- 这些元数据存储在系统表空间中
- 为了保证数据一致性，执行DDL时需要获取元数据锁（MDL锁）
- 这种锁定机制与普通事务的锁定机制不兼容
- 文件系统操作
- DDL操作往往涉及底层文件系统的改动
- 例如：创建/删除表时需要创建/删除物理文件
- 修改表结构时可能需要重建表文件
- 文件系统操作通常不能像数据库事务那样简单回滚
- 涉及到操作系统层面的文件操作，难以保证原子性
- 性能考虑
- DDL操作通常比较耗时
- 如果支持事务，就需要：
- 保持长时间的锁定
- 维护大量的日志信息
- 占用更多的系统资源
- 这会严重影响数据库的整体性能
- 实现复杂性
- 需要维护额外的回滚日志
- 需要处理各种边界情况
- 需要协调多个系统组件（文件系统、锁管理器、日志系统等）
- 实现成本高，容易引入新的bug
- 历史原因
- 早期的MySQL设计就没有考虑DDL事务支持
- 后续要添加这个特性需要对核心架构做大量改动
- 可能影响现有功能的稳定性
这就是为什么即使在MySQL 8.0引入了原子DDL，也仅仅是保证了DDL操作本身的原子性，而不是完整的事务支持。
建议在实际使用中：
- 将DDL操作与普通业务操作分开执行
- DDL操作前做好备份
- 有条件的话使用在线变更工具（如gh-ost、pt-online-schema-change）
- 制定清晰的回滚方案
- 在执行DDL操作时，确保没有未提交的事务
- 不要依赖DDL的回滚功能
- 在进行架构变更时，最好在业务低峰期进行
