必须用InnoDB：因支持事务、行级锁和崩溃恢复，而MyISAM不支持事务、仅表级锁且崩溃后数据不一致；仅纯只读归档表在严格条件下可选MyISAM。
写操作多或需要事务，必须用 InnoDB
只要业务里有“要么全成、要么全败”的逻辑（比如扣库存同时改订单状态），InnoDB 就不是可选项，而是底线。MyISAM 完全不支持事务：BEGIN 和 COMMIT 在它身上无效，每条语句独立落盘；一旦中途崩溃（断电、kill -9），数据只写了一半，且无法回滚。
常见错误现象：
- 用 MyISAM 做订单表，支付成功但库存没扣 → 数据永远不一致
-
UPDATE执行到一半失败，.MYD 和 .MYI 文件内容已不同步，后续SELECT直接报Incorrect key file for table
实操建议：
- 任何带用户交互的在线系统（CMS 后台、电商下单页、权限变更），默认选
InnoDB - 哪怕只是后台定时任务批量更新，只要涉及多表联动或状态流转，也得用
InnoDB - MyISAM 的
AUTO_INCREMENT不受事务保护：回滚后自增值不会退，而InnoDB会（MySQL 8.0+ 行为略有调整，需验证）
高并发写入时，MyISAM 的表级锁会拖垮 I/O
MyISAM 对所有写操作（INSERT、UPDATE、DELETE）都加整张表的排他锁。一个慢查询（比如 WHERE text_column LIKE '%xxx%'）卡住，后面所有读写全排队，iowait% 很快突破 40%，内核 I/O 队列堆积。
InnoDB 默认行级锁，UPDATE users SET status=1 WHERE id=123 只锁那一行；其他线程仍可读/写别的记录。更关键的是，它的 I/O 模式可控：
- MyISAM 每次写都要同步更新 .MYD 和 .MYI 两个文件 → 至少两次随机 I/O
- InnoDB 先顺序写
ib_logfile*，再异步刷脏页 → I/O 更平滑，innodb_io_capacity可直接绑定 SSD 的 IOPS 能力 - 突发写峰值（如秒杀）下，MyISAM 容易触发 I/O 雪崩；InnoDB 的
innodb_adaptive_flushing能动态压平毛刺
别信 “MyISAM 的 COUNT(*) 快” —— 快的是假数
MyISAM 把行数缓存在内存里，SELECT COUNT(*) FROM t 直接返回变量值；InnoDB 要扫描索引（通常是主键），结果取决于当前事务隔离级别下可见的行数。这不是性能问题，是语义陷阱。
容易踩的坑：
- MyISAM 的计数在崩溃后不可信，重启后可能仍是旧值，导致应用误判（比如以为还有库存，实际已售罄）
- MyISAM 全表扫描虽快，但代价是牺牲崩溃一致性；一旦异常退出，
REPAIR TABLE会引发更大 I/O 风暴 - SSD 上随机读性能已接近顺序读，MyISAM “数据文件连续”的物理优势基本失效
实操建议：如果真需要快速统计，用覆盖索引 + COUNT(1) 或单独维护计数表，别依赖引擎内置缓存。
MyISAM 唯一还说得通的场景：纯只读归档表
仅当同时满足以下全部条件时，MyISAM 的 I/O 行为才可能带来净收益：
- 表完全只读（无任何
INSERT/UPDATE/DELETE） - 不要求崩溃恢复（允许丢失最后几秒数据）
- 用
myisampack压缩过（myisampack -f table.MYI），且确认后续永不写入 - 没有外键依赖，也不参与任何事务链
注意：ALTER TABLE ... ENGINE=MyISAM 会丢掉外键、事务能力，且 MyISAM 不校验原表数据一致性 —— 如果源表（InnoDB）已有坏页，切换后可能直接报错。线上大表改引擎前，务必先在从库试跑 SHOW CREATE TABLE 确认输出干净。
云数据库（RDS）上基本没理由选 MyISAM：底层存储已做 I/O 隔离，“轻量”反而失去意义，而事务和崩溃恢复能力才是刚需。
