ROLLBACK无效的根本原因是事务未真正开启或已被隐式提交；MySQL默认autocommit=1，每条DML自动提交，需显式START TRANSACTION并确保表引擎为InnoDB，且避免DDL触发隐式提交。
ROLLBACK执行前事务是否真的已开启
很多情况下，rollback没效果，是因为它根本没作用在事务里——mysql 默认是 autocommit=1 模式，每条 insert/update/delete 语句执行完就自动提交了，后续再执行 rollback 实际上没有可回滚的内容。
验证方式：在 phpMyAdmin 的 SQL 窗口执行 SELECT @@autocommit;，返回 1 就说明自动提交开着，必须先关掉：
-
SET autocommit = 0;（影响当前连接后续所有语句） - 或显式用
START TRANSACTION;/BEGIN;开启一个新事务（推荐，作用范围明确）
注意：START TRANSACTION 必须在你要保护的 SQL 语句之前执行，且不能被中间的错误语句打断。
表引擎不是 InnoDB 导致事务不生效
MyISAM、Memory 等引擎完全不支持事务，哪怕你写了 START TRANSACTION 和 ROLLBACK，数据库也只会默默忽略事务控制逻辑，所有 DML 立即落盘。
检查方法：执行 SHOW TABLE STATUS LIKE 'your_table_name';，看 Engine 字段是否为 InnoDB。
- 如果不是，用
ALTER TABLE your_table_name ENGINE = InnoDB;转换（注意大表转换可能锁表、耗时） - 新建表时务必指定
ENGINE=InnoDB，例如：CREATE TABLE t (id INT) ENGINE=InnoDB;
phpMyAdmin 的“结构”页里也能看到引擎类型，但别只靠界面判断——有些旧版会缓存显示，以 SHOW TABLE STATUS 结果为准。
DDL 语句触发了隐式提交
像 CREATE、ALTER、DROP、TRUNCATE 这类 DDL 语句，在 InnoDB 中会强制提交当前事务，并开启一个新事务。这意味着：如果你在事务中混用了 DDL 和 DML，ROLLBACK 只能回滚 DDL 之后的 DML，而 DDL 之前的 DML 已经被悄悄提交了。
- 典型陷阱：
START TRANSACTION; UPDATE t SET x=1; ALTER TABLE t ADD COLUMN y INT; ROLLBACK;→UPDATE实际已生效 - 解决办法：把 DDL 操作单独拿出来，在事务外执行；或确认 DDL 前后不需要原子性保障
另外，RENAME TABLE、ANALYZE TABLE 等语句也有同样行为，不能当作普通 DML 处理。
phpMyAdmin 页面刷新或超时导致事务中断
phpMyAdmin 是无状态 Web 应用，它的 SQL 执行依赖于 PHP 进程和 MySQL 连接。如果执行时间过长、页面手动刷新、浏览器关闭、或服务器端设置了短超时（如 max_execution_time 或 wait_timeout），MySQL 连接会断开，未 COMMIT 的事务自动回滚——但这个回滚是服务端做的，你不会看到提示，更不会触发你写的 ROLLBACK 语句。
- 查当前连接空闲时长：
SHOW VARIABLES LIKE 'wait_timeout';（默认通常 28800 秒，但共享主机可能设成 60 秒） - 避免长事务：复杂操作拆成小步，或改用命令行客户端（如
mysql -u root -p）直连 - 不要依赖 phpMyAdmin 的“事务控制按钮”——它只是快捷执行
START/COMMIT/ROLLBACK，底层仍受连接生命周期限制
真正可靠的事务控制，从来不在浏览器里做；它需要稳定连接、明确边界、以及对引擎和语句类型的清醒认知。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
