InnoDB原生支持事务，具备redo log、undo log、MVCC和外键等完整事务组件；MyISAM无事务机制，不支持回滚、崩溃恢复和外键约束，其START TRANSACTION、COMMIT等操作均被忽略。
事务能力是引擎底层实现决定的，不是配置开关
MySQL 的 InnoDB 和 MyISAM 是两种完全独立实现的存储引擎，事务支持与否不是靠 SET 命令或配置项开启/关闭的——InnoDB 在设计之初就内置了 redo log、undo log、MVCC 和事务状态管理模块；而 MyISAM 根本没有这些组件，它的写操作就是直接刷磁盘文件（.MYD），连“未提交”这个概念都不存在。
你执行 START TRANSACTION 在 MyISAM 表上不会报错，但后续的 COMMIT 或 ROLLBACK 全部被忽略。这不是兼容性妥协，是代码里压根没处理这些命令的分支逻辑。
MyISAM 执行 UPDATE 时崩溃，为什么不能回滚？
MyISAM 没有 undo log，也没有事务上下文跟踪机制。它对每一行的修改都是“覆写式”的：找到 .MYD 文件里的物理偏移，把新值直接写进去。一旦写了一半断电，那部分数据就永久处于中间态——比如订单表中金额改了一半、状态字段却没更新，这种脏数据无法自动识别，更无法还原。
对比 InnoDB：所有变更先记入 ib_logfile*（redo log），同时在 buffer pool 中生成旧版本镜像（undo log）。哪怕进程被 KILL，重启后也能靠日志重放 + 清理未提交事务，确保数据要么全在、要么全不在。
-
MyISAM崩溃后常见错误：Table is marked as crashed - 修复必须人工运行：
REPAIR TABLE，且不保证语义正确（比如自增 ID 跳变、部分行丢失） -
InnoDB崩溃恢复是秒级自动完成，业务无感
为什么 MyISAM 表上加 FOREIGN KEY 不生效？
MyISAM 解析建表语句时会识别 FOREIGN KEY 语法，但直接丢弃，不报错也不建约束。这意味着：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
你删父表某条记录，子表对应外键字段的值还在，变成“孤儿数据”；你插入子表一条非法外键值，也不会被拦截——因为校验逻辑根本没注册进引擎的 DML 流程。
InnoDB 则不同：外键定义会触发索引创建、锁策略调整和实时检查钩子。例如 ON DELETE CASCADE 会在父行删除时自动加锁并清理子行，整个过程包裹在同一个事务中，可回滚。
- MyISAM 允许你写
FOREIGN KEY (a) REFERENCES t2(b)，但SHOW CREATE TABLE输出里不会显示该约束 - InnoDB 下若违反外键，明确报错：
ERROR 1452 (23000): Cannot add or update a child row - 外键依赖事务机制，MyISAM 没事务，自然也撑不起外键
现在还有理由选 MyISAM 吗？
极少数场景下仍可能见到 MyISAM：比如只读归档表（历史日志）、全文检索需求强且不用事务（注意 MySQL 5.6+ InnoDB 也支持全文索引）、或遗留系统尚未迁移。但要注意：
MySQL 8.0 已将所有系统表强制改为 InnoDB，库内不再允许新建 MyISAM 系统表；很多运维工具（如 pt-table-checksum）默认跳过 MyISAM 表，数据一致性难验证；并发写入稍一升高，Waiting for table level lock 就会频繁出现。
真正需要纠结引擎选择的时刻，基本只发生在迁移老系统时——而迁移本身，往往就意味着要把 MyISAM 表转成 InnoDB。不是因为“功能更多”，而是因为数据不能错、服务不能停、故障不能靠人修。
