事务提交后数据未出现，先查表引擎是否为InnoDB；MyISAM等引擎不支持事务，COMMIT无效；DDL语句（如ALTER TABLE）会隐式提交事务，导致前置DML无法回滚；autocommit=1时BEGIN无效；需显式设SET autocommit=0并验证，且确保网络、刷盘策略与连接池配置正确。
事务提交后数据没出现，先查引擎是不是InnoDB
不是所有MySQL表都支持事务提交后“真正落地”，MyISAM、Memory这类引擎压根不记录undo log和redo log，哪怕你写了COMMIT，数据也早就直接写进去了，回滚不了，提交也不算数——它根本没事务状态可维护。
验证方式很简单：
-
SHOW CREATE TABLE 表名;看输出里有没有ENGINE=InnoDB - 或者查系统表：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = '库名' AND TABLE_NAME = '表名';
如果发现是MyISAM，别犹豫，立刻改：ALTER TABLE 表名 ENGINE=InnoDB;。注意：这个操作会锁表，生产环境建议在低峰期执行。
DDL语句（如ALTER TABLE）触发了隐式提交
你在事务里执行了CREATE、DROP、ALTER或TRUNCATE？那恭喜，前面所有INSERT/UPDATE已经自动COMMIT了，后续ROLLBACK完全无效——MySQL强制把DDL当作事务分界点。
典型翻车场景：
- 在转账逻辑里顺手
ALTER TABLE accounts ADD COLUMN version INT，结果扣款成功、入账失败，但扣款没回滚 - 批量导入前建临时表：
BEGIN; CREATE TEMPORARY TABLE ...; INSERT INTO ...; ROLLBACK;→ 前面的INSERT已落盘
解决办法只有一条：DDL必须放在事务块之外。建表、加字段、删索引这些操作，和业务DML严格隔离。
autocommit=1 时 BEGIN 没起作用
MySQL默认autocommit=1，此时BEGIN或START TRANSACTION只是临时切换会话模式，一旦遇到任何错误、连接中断、甚至客户端异常退出，事务就静默终结——你看到COMMIT返回成功，其实什么都没发生。
更隐蔽的是应用层驱动行为：
- Python的
pymysql默认开启autocommit=True，conn.begin()不关自动提交，等于白开 - Java JDBC连接串漏配
?useSSL=false&autoReconnect=true&allowPublicKeyRetrieval=true，某些版本会重置autocommit状态 - Spring Boot里
@Transactional方法被本类内非@Transactional方法调用，AOP失效，实际走的是自动提交路径
安全做法：显式关闭并验证
SET autocommit = 0;<br>SELECT @@autocommit;
返回0才算真正进入手动事务模式。
网络假成功 + 服务端已丢上下文
客户端收到OK包不代表数据已刷盘。尤其在以下情况：
- MySQL配置了
innodb_flush_log_at_trx_commit = 0（仅写log buffer，不fsync），断电即丢 - 连接池配置了
testOnBorrow=true但没设validationQuery=SELECT 1，连接复用时旧事务残留 - 应用层收到
MySQL server has gone away后仍尝试发COMMIT，MySQL已释放该连接的事务ID
关键业务必须加幂等确认：
提交后立刻执行SELECT ... FOR UPDATE查刚写入的数据，查不到就说明没生效，得重试或告警；不要依赖网络层返回值。
真正容易被忽略的点是：事务生效 ≠ 数据可见 ≠ 数据持久。三者分别依赖引擎能力、隔离级别设置、以及innodb_flush_log_at_trx_commit的刷盘策略。任何一个环节松动，都会导致“明明commit了却像没发生”。
