MySQL 5.5后默认改用InnoDB，因其支持事务、行级锁、外键及崩溃可恢复，满足现代业务对原子性、高并发和数据一致性的核心需求。
为什么 MySQL 5.5 后默认改用 InnoDB
因为 MyISAM 不支持事务，而现代业务几乎离不开原子性操作——比如下单扣库存+写订单+减余额，这三步必须全成功或全失败。InnoDB 从 5.5 开始成为默认引擎，不是技术炫技，是它能靠 redo log 和 undo log 实现真正的崩溃可恢复、异常可回滚。
实操中你可能没意识到：哪怕只执行一条 UPDATE，MyISAM 也是立即落盘、无法撤回；而 InnoDB 默认开启自动提交（autocommit=1），但只要你显式写 BEGIN + COMMIT 或 ROLLBACK，就能控制边界。这点在迁移老项目时最容易被忽略——直接把 MyISAM 表转成 InnoDB，却不检查应用层是否依赖“无事务”的行为（比如靠写一半中断来调试），就会出隐蔽数据错乱。
表级锁 vs 行级锁：高并发下卡在哪
MyISAM 用的是表级锁，意味着一个 UPDATE 正在跑，整张表的 SELECT、INSERT 全得排队。InnoDB 用行级锁，同一张表里张三改第 5 行、李四改第 200 行，互不干扰。
- 常见错误现象：
SHOW PROCESSLIST看到一堆Waiting for table level lock，其实是 MyISAM 在告警 - 使用场景：用户中心表、订单表这类读写混杂、更新频繁的，MyISAM 一压就堵死；纯静态日志归档表（如
access_log）倒可以继续用 MyISAM，毕竟只追加不修改 - 注意坑点：InnoDB 的行锁不是“天然免费”的——没走索引的
WHERE条件（比如WHERE status=1但status没建索引），会升级为表锁，效果和 MyISAM 一样
外键和 COUNT(*) 性能：两个典型取舍点
InnoDB 支持外键，能靠数据库层强制约束关联完整性；MyISAM 不支持，所有逻辑得堆在代码里，容易漏、难维护。但反过来看，SELECT COUNT(*) FROM table 这种语句，MyISAM 是秒出（它自己存着总行数），InnoDB 得扫一遍聚簇索引——4 万行数据，MyISAM 耗时约 105μs，InnoDB 可能超 10ms。
- 别盲目优化
COUNT(*)：如果只是做分页总数展示，用缓存或近似值更实际；真要精确且高频，考虑加汇总表或用INFORMATION_SCHEMA.TABLES查估算值 - 外键不是银弹：级联删除（
ON DELETE CASCADE）看着省事，但大表上可能触发隐式全表扫描，反而拖慢主业务 - 迁移提示：用
ALTER TABLE t ENGINE=InnoDB转换时，确保目标表有主键——InnoDB 强制要求，没主键会自动建隐藏主键，导致辅助索引变大、性能下降
崩溃后还能不能找回数据
MyISAM 崩溃后，轻则 Table is marked as crashed，重则部分数据永久丢失，只能靠 REPAIR TABLE 碰运气；InnoDB 崩溃重启后，自动用 redo log 重放已提交事务、用 undo log 回滚未完成事务，只要日志文件没损坏，数据一致性就有保障。
但这有个关键前提：你的 innodb_flush_log_at_trx_commit 配置得对。设成 0 或 2 虽然快，但断电可能丢 1 秒事务；生产环境建议保持默认 1——每次事务都刷盘，慢一点，但数据真正落地了。很多人图快改成 2，结果遇上机房断电，发现最后一批订单全没了。
真正复杂的地方不在选引擎，而在理解你的业务到底需要什么级别的安全和并发能力。MyISAM 没被淘汰，只是退到了它该在的位置：极简、只读、可压缩的归档场景。其他地方硬上，迟早要补课。
