Navicat事务回滚后数据仍存在，说明回滚未执行成功或根本未处于可回滚事务中：一是autocommit=1时每条DML自动提交，ROLLBACK无效；二是表视图编辑走行级更新协议，非标准事务，影响0行即未生效；三是连接中断后旧事务已失效，ROLLBACK成空操作；四是DDL语句触发隐式提交，导致前置DML无法回滚；五是Navicat“回滚”按钮仅作用于表编辑，对查询窗口手动事务无响应。
navicat事务回滚后数据仍然存在，基本可以确定：回滚根本没执行成功，或者你压根没处在可回滚的事务中。
事务根本没开启或已自动提交
Navicat默认是“自动提交”模式（autocommit=1），只要执行一条INSERT、UPDATE或DELETE，数据库立刻持久化，后续ROLLBACK对它完全无效。
- 检查当前会话是否关闭了自动提交：
SELECT @@autocommit;—— 返回1就是开启状态 - 想手动控制事务，必须先显式执行：
START TRANSACTION;或BEGIN; - Navicat界面底部状态栏会显示“事务已开始”或出现灰色/亮起的
√图标，这才是真正进入事务上下文
你执行的是表视图编辑，不是SQL事务
在Navicat双击打开表、直接修改单元格再点√，这套操作走的是“行级更新协议”，不是标准SQL事务流程。它底层会生成类似UPDATE ... WHERE id = ? AND col1 = ? AND col2 = ?的语句 —— 一旦WHERE条件不匹配（比如没主键、主键失效、数据被并发改过），就会“影响0行”，表面成功实则没改任何东西，自然也谈不上回滚。
- 确认表有且仅有一个主键（或唯一非空索引），否则Navicat无法准确定位行
- 修改后别急着刷新，先看底部提示：“受影响行数：X” —— 如果是
0，说明更新失败，不是回滚问题，是根本没生效 - 这种编辑方式不会触发
ROLLBACK，因为每条修改都是独立自动提交的
ROLLBACK执行时连接已断开或事务已结束
事务只对当前数据库连接有效。如果你在Navicat里执行了START TRANSACTION，然后窗口卡死、网络中断、或Navicat意外退出，再重新连上时，那个事务早已被数据库自动终止或丢弃，此时再发ROLLBACK只是空操作，毫无效果。
- 执行
ROLLBACK前，先确认连接是否活跃：SELECT 1;能返回结果才算有效 - 不要依赖“历史SQL记录”去重跑
ROLLBACK——旧事务ID已失效，它只对刚开启的那个会话管用 - Navicat的“查询”窗口和“表数据”窗口使用不同连接句柄，一个窗口里的事务对另一个窗口不可见
存储过程或触发器干扰了回滚行为
某些存储过程中包含隐式提交（如DDL语句ALTER TABLE、CREATE TEMPORARY TABLE），一旦执行，会强制提交当前事务，导致前面的DML操作无法被后续ROLLBACK撤销。
- MySQL中，任何DDL都会触发隐式
COMMIT，哪怕它写在START TRANSACTION之后 - 检查你的SQL是否混用了DML和DDL；或者存储过程里调用了含DDL的子过程
- 触发器中抛出异常（如
SIGNAL SQLSTATE '45000'）可能被上层忽略，导致你以为回滚了，其实只中断了触发器本身
最常被忽略的一点：Navicat的“回滚”按钮（工具栏上的弯曲箭头）只对它自己发起的表编辑操作有效，对你在查询窗口手工写的START TRANSACTION完全无感 —— 它不共享事务上下文。要真正回滚，必须回到同一查询窗口，手动输入ROLLBACK;并执行。
