InnoDB 支持完整的 ACID 事务处理，具备回滚、崩溃恢复和外键约束能力，是涉及数据一致性场景的唯一推荐选择；MyISAM 不支持事务，写入中断易导致数据损坏，仅适用于只读或数据丢失可接受的临时表场景。
先说结论：生产环境必须选 InnoDB，MyISAM 因缺乏事务支持已不再适用于核心业务。
- 适合：金融交易、订单库存、用户账户等要求数据强一致性的业务
- 重点看：锁机制（行锁 vs 表锁）与日志恢复能力（redo/undo log）
- 别忽略：MySQL 5.5 版本后默认引擎已变更为 InnoDB，新建表无需额外指定
快速处理思路
若需确认当前表使用的存储引擎或进行引擎转换，可通过以下 SQL 命令快速查看和调整。
SHOW TABLE STATUS LIKE '表名'; ALTER TABLE 表名 ENGINE=InnoDB;
执行转换前务必备份数据，因为引擎转换过程涉及数据文件重构，中断可能导致表不可用。
为什么会这样
两者在事务支持上的差异源于设计目标不同：InnoDB 为数据安全与高并发设计，MyISAM 为简单读取速度设计。InnoDB 通过 undo log 实现事务回滚，通过 redo log 保障崩溃后数据不丢失，确保操作要么全部成功要么全部失败。MyISAM 没有日志机制，写操作直接落盘，一旦服务器断电或进程崩溃，正在写入的数据页可能损坏且无法自动恢复，因此无法支持事务的原子性和持久性。
分步处理
若发现业务表误用了 MyISAM 引擎，可按以下步骤迁移至 InnoDB 以获取事务支持。
1. 确认当前引擎
使用 SHOW TABLE STATUS 命令查看表当前的 Engine 字段，确认是否为 MyISAM。
2. 数据备份
使用 mysqldump 工具导出表结构及数据，防止转换过程中出现意外导致数据丢失。
3. 执行转换
执行 ALTER TABLE 语句将引擎修改为 InnoDB，大表转换可能需要较长时间，建议在低峰期操作。
4. 验证索引
转换后检查主键索引是否存在，InnoDB 必须有主键（未定义则生成隐藏主键），确保行锁能正常生效。
怎么验证是否生效
转换完成后，通过手动测试事务回滚功能来验证 InnoDB 事务支持是否正常工作。
1. 开启事务
执行 START TRANSACTION; 开启一个事务会话。
2. 修改数据
执行 UPDATE 语句修改某行数据，此时不要提交。
3. 回滚操作
执行 ROLLBACK; 命令，然后查询该数据，若数据恢复为修改前的值，说明事务支持生效。
4. 检查引擎
再次运行 SHOW TABLE STATUS，确认 Engine 字段显示为 InnoDB 且 Create_options 中包含 transactional 标识。
常见坑
1. 隐式提交风险
某些 DDL 语句（如 ALTER TABLE）在 InnoDB 中会触发隐式提交，导致事务意外结束，需在代码逻辑中规避。
2. 行锁退化
InnoDB 的行锁依赖索引，若 SQL 查询未命中索引，行锁会退化为表锁，并发性能会下降至接近 MyISAM 水平。
3. COUNT(*) 差异
MyISAM 内部维护行数计数器，COUNT(*) 极快；InnoDB 需扫描索引树，大数据量下速度较慢，但 MySQL 8.0 后优化明显。
4. 崩溃恢复误区
不要依赖 MyISAM 的 repair table 修复损坏数据，物理文件损坏往往不可逆，核心数据必须使用 InnoDB。
常见问题
InnoDB 和 MyISAM 能混合使用吗
可以，但不推荐。同一个数据库中不同表可以使用不同引擎，但跨引擎事务不支持，外键约束也无法在引擎间建立。
MyISAM 在什么场景下还能用
仅适用于日志记录、临时数据缓存或只读数据仓库等数据丢失可接受、几乎无写入的场景。
为什么默认引擎是 InnoDB
因为现代应用对数据一致性和并发写入的要求远高于纯读取速度，InnoDB 的事务和行锁机制更能保障业务安全。
参考来源
- innodb 和 myisam 有什么区别_mysql 引擎对比
- mysql innodb 和 myisam 有什么区别
- MySQL 存储引擎:MyISAM 与 InnoDB 核心差异详解
- 对比 InnoDB 和 MyISAM 存储引擎的差异
- MySQL - 一文理清存储引擎:InnoDB vs MyISAM 核心差异