默认选InnoDB是因为它在事务、并发、崩溃恢复三方面满足生产硬需求；MyISAM不支持事务且崩溃后需手动修复，线上不可靠。
为什么默认选 InnoDB？它真能扛住线上业务
MySQL 5.5 起就默认用 InnoDB，不是因为“新”，而是它在事务、并发、崩溃恢复这三块真正解决了生产环境的硬需求。如果你的表要支持 UPDATE、DELETE、高并发写入，或者哪怕只是怕断电丢数据，InnoDB 就不是“可选”，而是“必须”。MyISAM 看似快，但一遇异常重启，REPAIR TABLE 是常态，线上不敢赌。
行锁 ≠ 自动生效：索引没建对，照样锁全表
InnoDB 的行级锁只在**通过索引条件检索时才生效**——这是最容易踩的坑。比如你执行 UPDATE users SET status=1 WHERE name='Alice'，但 name 没建索引，InnoDB 就会退化为表锁，阻塞所有写操作。
- 确认是否走索引：用
EXPLAIN查看type是否为range/ref，而非ALL - 主键和唯一索引最稳妥；普通字段务必加索引再用于
WHERE或JOIN - 注意隐式类型转换：比如
WHERE id='123'（id是INT），会导致索引失效，锁升级
count(*) 为什么比 MyISAM 慢？不是引擎慢，是语义不同
InnoDB 不保存总行数，SELECT COUNT(*) FROM t 必须扫聚簇索引（即遍历所有主键页）——这不是性能缺陷，而是为了保证事务一致性。MyISAM 的“快”是靠牺牲隔离性换来的（它返回的是元数据缓存值，可能不准）。
- 如果确实需要高频精确总数，考虑用单独计数表 +
INSERT ... ON DUPLICATE KEY UPDATE维护 - 分页场景慎用
COUNT(*)，改用游标或覆盖索引估算（如COUNT(id)且id是主键） - MySQL 8.0+ 对
INFORMATION_SCHEMA中的统计信息做了优化，但仍是近似值，不可用于强一致性校验
崩溃后自动恢复？得看 redo log 和 doublewrite 是否启用
InnoDB 的崩溃恢复能力依赖两个关键机制：redo log（重做日志，确保已提交事务不丢）和 doublewrite buffer（防止页写入半截损坏）。但它们不是“默认开箱即用”的魔法开关——比如 innodb_doublewrite 在某些云数据库托管实例中可能被关闭以换性能。
- 检查状态：
SHOW VARIABLES LIKE 'innodb_log_file_size'、SHOW VARIABLES LIKE 'innodb_doublewrite' - 避免手动删除
ib_logfile*文件：可能导致 recovery 失败，报错InnoDB: Database page corruption - 若用 MySQL 5.7+，确认
innodb_fast_shutdown=1（默认），否则关机前会做完整 purge，拖慢停机时间
真正决定 InnoDB 是否可靠，从来不是“它支不支持事务”，而是你有没有让它的事务日志、缓冲池、双写机制在真实负载下持续有效工作——这些细节，比选引擎本身更值得花时间盯住。
