最直接确认事务是否被隐式提交的方法是用同一连接在操作前后查询 INFORMATION_SCHEMA.INNODB_TRX，若 TRX_STATE 从 RUNNING 变为空或无记录，即表明已隐式提交。
怎么确认事务是不是被隐式提交了
最直接的办法是查 INFORMATION_SCHEMA.INNODB_TRX，在可疑操作前后各执行一次对比：
- 执行
BEGIN; INSERT INTO t VALUES (1);后查一次，TRX_STATE应为RUNNING - 紧接着执行
ALTER TABLE t ADD COLUMN c INT;，再查一次 —— 如果返回空结果或TRX_STATE变成空值，说明事务已被隐式提交 - 注意：这个查询必须用同一个连接（
CONNECTION_ID()要一致），否则看不到上下文
别只盯着错误提示；隐式提交本身不报错，但 DDL 失败、字符集不匹配、触发器内部出错等前置问题，会藏在 SHOW WARNINGS 里。比如执行完 INSERT 就立刻 SHOW WARNINGS，可能看到 Warning 1366 Incorrect string value，这实际意味着事务早已中断，后续 ROLLBACK 必然失效。
哪些语句一定会触发隐式提交
MySQL 官方定义明确：所有 DDL 都强制提交当前事务，且无法回滚。这不是 bug，是设计行为。
- 典型语句包括：
CREATE、DROP、ALTER、TRUNCATE、RENAME TABLE、ANALYZE TABLE、OPTIMIZE TABLE -
LOCK TABLES和UNLOCK TABLES也会触发，哪怕只是加READ锁 -
SET AUTOCOMMIT = 1切换模式时，会立刻提交当前未提交的修改 - 唯一例外是
CREATE TEMPORARY TABLE，它不触发隐式提交
特别注意：START TRANSACTION 或 BEGIN 本身不提交，但如果之前已有未提交的 DML，MySQL 5.7+ 会在执行 BEGIN 前先隐式提交它们 —— 这个行为和 5.6 不同，容易误判。
为什么在存储过程里用事务包裹 DDL 也不行
因为隐式提交发生在语句执行时，不是语法解析时。即使你写成：
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
CREATE PROCEDURE p() BEGIN START TRANSACTION; INSERT INTO t VALUES (1); ALTER TABLE t ADD COLUMN x INT; ROLLBACK; END
执行时，ALTER 一执行，前面的 INSERT 就已落盘，ROLLBACK 对它完全无效。
- DDL 在 MySQL 中被定义为“非事务性操作”，InnoDB 引擎层不参与其事务控制
- 触发器里执行的 DDL 同样触发隐式提交，且更难察觉 ——
INNODB_TRX.TRX_QUERY只显示外层语句，不体现触发器内动作 - 想验证是否生效？用命令行快速复现：
mysql -e "BEGIN; INSERT INTO t VALUES(1); ALTER TABLE t ENGINE=InnoDB; ROLLBACK;"，然后查表，数据还在就坐实了
如何避免被隐式提交坑到生产环境
核心原则：DDL 和 DML 物理隔离。这不是权宜之计，而是必须遵守的边界。
- 把 DDL 操作单独拆到独立会话或脚本中执行，和业务事务彻底分开
- 应用层做协调：先完成所有 DML 并
COMMIT，再发 DDL 请求；或反过来，先 DDL 再 DML - 上线前用
EXPLAIN FORMAT=TREE或performance_schema.events_statements_history（需提前开启）回溯真实执行链，确认有没有隐藏的 DDL 或触发器调用 - 监控层面加一层兜底：对
INFORMATION_SCHEMA.INNODB_TRX做定时采样，如果发现事务TRX_STARTED时间很短但TRX_STATE突然消失，大概率是某处混入了 DDL
最容易被忽略的是触发器和存储过程里的隐式提交 —— 它们不会出现在慢日志或普通事务视图里，但会让锁等待、死锁、数据不一致等问题变得难以归因。排查时一定要查 information_schema.TRIGGERS 和死锁日志中带 NEW./OLD. 的语句片段。
