myisam执行begin/commit无效，因其缺失undo log、redo log、行级锁和mvcc等事务底层组件，server层仅语法接收，引擎层静默忽略；验证须用show create table确认engine=innodb。
MyISAM 表执行 BEGIN/COMMIT 为什么没用
因为 MyISAM 引擎压根没实现事务所需的底层组件：它没有 undo log，所以 ROLLBACK 被静默忽略；没有 redo log，崩溃后无法恢复未刷盘的修改；锁粒度是表级，也不支持 MVCC 或隔离级别切换。哪怕你写了 BEGIN 和 COMMIT，MySQL Server 层会接收语法，但 MyISAM 引擎根本不响应这些指令。
验证当前表是否真支持事务回滚
别靠猜测或 ORM 注解判断，直接查引擎类型：
- 查表定义：
SHOW CREATE TABLE your_table;→ 看输出中是否有ENGINE=InnoDB - 查所有引擎支持情况：
SHOW ENGINES;→ 找SUPPORT=DEFAULT或YES且TRANSACTIONS=YES的行 - 查默认引擎：
SELECT @@default_storage_engine;→ 如果是MyISAM，新建表不显式指定引擎就默认不支持事务
ALTER TABLE ENGINE=InnoDB 的实际限制
改引擎不是语法执行完就万事大吉，得注意兼容性断点：
- 全文索引在 InnoDB 中从 MySQL 5.6+ 才原生支持；低于该版本需先
DROP INDEX，改完再重建 -
ALTER TABLE your_table ENGINE = InnoDB;是在线 DDL（5.6+），但大表仍可能锁表数秒，生产环境建议在低峰期操作 - 改完必须验证：
SELECT ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA='db_name' AND TABLE_NAME='your_table';→ 确保返回值是InnoDB - 绝对不要对 InnoDB 表运行
myisamchk或REPAIR TABLE—— 工具不兼容，会损坏数据页
为什么不能靠应用层“模拟”事务回滚
有些方案建议用存储过程 + 条件判断 + DELETE 补救来“绕过” MyISAM 限制，这本质是误导：
-
ROLLBACK在 MyISAM 中永远不生效，哪怕写在存储过程里也一样 - 所谓“回滚”只是应用层补偿逻辑，不具备原子性：中间步骤失败时，之前已执行的
INSERT或UPDATE无法撤销 - 并发场景下，两个会话同时读-改-删，极易产生竞态，导致数据错乱
真正可靠的事务边界，只存在于 InnoDB 引擎、显式 BEGIN / COMMIT、且所有操作在同一连接内这三个条件同时满足时。缺一不可，而最容易被忽略的，是连接复用和 ORM 自动提交行为对事务边界的隐式破坏。
