MySQL 5.5后默认改用InnoDB，因其支持事务、行级锁、外键及崩溃可恢复，满足现代业务对原子性、高并发和数据一致性的核心需求。
MySQL 5.5 之后默认用 InnoDB，不是权衡取舍的结果，而是 MyISAM 在现代业务场景下已经无法满足基本数据可靠性要求——它连事务和行锁都没有，根本撑不起一个需要并发写、一致性和崩溃恢复的系统。
为什么 MySQL 5.5 强制切换默认引擎
核心动因就一条：MyISAM 的表级锁 + 无事务机制，在 Web 应用高并发写入时会直接卡死。比如用户同时下单、扣库存、记日志，MyISAM 只能串行执行，而 InnoDB 的行级锁允许不同订单操作不同行，互不阻塞。
-
InnoDB自带redo log和undo log，崩溃后可自动前滚/回滚，MyISAM 崩溃后只能靠REPAIR TABLE猜数据 - MyISAM 的
COUNT(*)虽快（缓存了行数），但结果不准（不加锁统计，脏读风险）；InnoDB每次扫表虽慢，但结果严格一致 - 外键约束、MVCC、间隙锁这些保障 OLTP 场景一致性的能力，MyISAM 全都不支持
SHOW VARIABLES LIKE 'default_storage_engine' 返回 InnoDB 就够了吗
不够。这个变量只控制 CREATE TABLE 不显式指定 ENGINE 时的默认值，但已有表不受影响。你可能在旧库中看到大量 ENGINE=MyISAM 的表，它们不会自动迁移。
- 检查具体表引擎：
SHOW CREATE TABLE user_log;看输出里是否含ENGINE=InnoDB - 批量转换风险高：大表
ALTER TABLE t ENGINE=InnoDB会锁表、占磁盘空间翻倍，线上务必避开高峰 - 某些特性会隐式退化：比如 MyISAM 支持
FULLTEXT索引（5.6 前），而早期InnoDB不支持，升级后需确认全文检索逻辑是否断掉
InnoDB 的关键能力不是“比 MyISAM 多功能”，而是解决具体问题
别把 InnoDB 当成万能膏药。它的设计目标非常明确：让事务不丢、并发不卡、崩溃能救。为此付出的代价是更重的内存占用、更复杂的锁机制、以及某些只读场景下的性能损失。
- 主键设计直接影响性能：
InnoDB是聚簇索引，主键越短越好；用 UUID 做主键会导致二级索引体积暴增 - 默认隔离级别是
REPEATABLE READ，但靠的是 next-key lock（行锁 + 间隙锁），不是简单快照；幻读防护带来额外锁开销 -
innodb_buffer_pool_size必须调大（通常设为物理内存 50%~75%），否则大量磁盘 IO 会让性能反不如 MyISAM
真正容易被忽略的点是：InnoDB 的优势只在「写多读多」或「强一致性要求」时才成立。如果你的表纯粹是静态配置、每月导入一次、只读查询——MyISAM 依然更快更省资源。选引擎不是看默认值，而是看你的 SELECT/INSERT/UPDATE/DELETE 比例、是否容忍丢失、能否接受锁表修复。
