事务回滚是否能保证数据一致性？
能，但前提是事务必须在
START TRANSACTION或
BEGIN之后、
COMMIT之前显式执行
ROLLBACK，且所有操作都在同一个事务上下文中。MySQL 默认的
AUTOCOMMIT=1模式下，单条语句自动提交，此时
ROLLBACK无效——这是最常被忽略的前提。 检查当前 autocommit 状态：
SELECT @@autocommit;，返回
1表示开启自动提交 临时关闭：执行
SET autocommit = 0;后，后续语句才进入事务边界 DDL 语句（如
CREATE TABLE、
ALTER TABLE）会隐式触发
COMMIT，导致之前未提交的 DML 回滚失效 跨连接的操作无法被同一事务控制，不同连接中的
INSERT和
UPDATE不受彼此事务影响
什么情况下 ROLLBACK 实际上没起作用？
常见于误判“已入事务”或混淆存储引擎行为。InnoDB 支持完整事务，MyISAM 完全不支持事务——哪怕写了
BEGIN和
ROLLBACK，MyISAM 表的数据也早已落盘。 确认表引擎：
SHOW CREATE TABLE user_info;查看输出中是否含
ENGINE=InnoDB执行
ROLLBACK后立刻查表，若数据仍在，先检查是否在
AUTOCOMMIT=1下执行了单条语句 使用
SELECT ... FOR UPDATE或
LOCK IN SHARE MODE时，若事务未提交就断开连接，MySQL 会自动回滚并释放锁，但客户端可能误以为“已生效” 触发器中抛出异常（如
SIGNAL SQLSTATE '45000'）可中断事务，但需确保触发器本身在事务内被调用，而非独立执行
如何验证一次 ROLLBACK 真正生效了？
不能只依赖“没报错”，要观察数据状态和事务 ID 变化。InnoDB 的
INFORMATION_SCHEMA.INNODB_TRX表可实时反映活跃事务，配合
SELECT查询比对最可靠。
START TRANSACTION;
INSERT INTO user_info (name, balance) VALUES ('alice', 100);
SELECT * FROM user_info WHERE name = 'alice'; -- 能查到新记录
SELECT trx_id, trx_state FROM INFORMATION_SCHEMA.INNODB_TRX
WHERE trx_mysql_thread_id = CONNECTION_ID(); -- 显示 active 状态
ROLLBACK;
SELECT * FROM user_info WHERE name = 'alice'; -- 应返回空结果
SELECT trx_id FROM INFORMATION_SCHEMA.INNODB_TRX
WHERE trx_mysql_thread_id = CONNECTION_ID(); -- 应无结果
ROLLBACK成功后，
INFORMATION_SCHEMA.INNODB_TRX中对应线程的记录消失 若仍能看到该事务，说明
ROLLBACK未执行或执行失败（例如语法错误、权限不足） 避免用
SHOW PROCESSLIST判断，它不显示事务状态，只显示连接命令
高并发下回滚对一致性还有保障吗？
有，但保障范围仅限于本事务内的修改。InnoDB 的 MVCC 机制让其他事务看到的是快照，不会因你的
ROLLBACK导致它们读到“中间态”。不过，若多个事务竞争同一行，回滚前的锁等待可能引发超时或死锁，进而影响整体一致性达成时机。 死锁检测由 MySQL 自动触发，报错
Deadlock found when trying to get lock后必须重试逻辑，不能假设
ROLLBACK就万事大吉
SELECT ... FOR UPDATE在事务中加锁，若另一事务已持有锁且未提交，当前事务会阻塞；此时
ROLLBACK只释放本事务锁，不解除对方阻塞 长事务增加 undo log 压力，可能导致
ROLLBACK执行缓慢甚至失败（如磁盘满、超时），应避免在事务中做耗时查询或网络调用
事务真正落地前，任何“看起来回滚了”的判断都得靠查数据+查
INNODB_TRX双验证。引擎、autocommit、连接隔离、锁状态——少盯住一个，就容易以为一致，其实已经偏移。
