当前支持的存储引擎需执行 SHOW ENGINES; 查看，Support 为 YES 的可用，DEFAULT 表示默认；InnoDB 因事务、行级锁、崩溃恢复、外键等硬需求成为首选；MyISAM 仅适用于纯读、无事务、可接受损坏风险的极窄场景；MEMORY 和 ARCHIVE 各有严重限制，应谨慎使用。
怎么查当前支持哪些存储引擎
直接执行 SHOW ENGINES;，结果中 Support 列为 YES 的就是可用引擎，DEFAULT 表示当前默认值。别只看文档说“支持”，有些引擎（比如 FEDERATED 或 ARCHIVE）可能没启用，得确认实际状态。
InnoDB 为什么几乎总是首选
它不是“功能多才被默认”，而是因为现代业务绕不开的几个硬需求它都扛住了：
• 事务：用 BEGIN/COMMIT/ROLLBACK 控制数据一致性，订单、支付、库存扣减全靠它兜底
• 行级锁：并发写时不会整张表卡死，UPDATE users SET balance = balance - 100 WHERE id = 123 只锁这一行
• 崩溃恢复：断电或宕机后靠 Redo Log 和 Undo Log 自动修复，不用人工跑修复脚本
• 外键：数据库层强制关联约束，避免应用逻辑漏校验导致脏数据
注意：SELECT COUNT(*) 会全表扫描（不存行数），别拿它做实时总条数统计；全文索引从 MySQL 5.6 起才支持，老版本别试。
MyISAM 还有没有用武之地
有，但非常窄——仅限「纯读、无事务、能接受损坏风险」的场景，比如：
• 历史日志归档表（只 INSERT + SELECT，永不 UPDATE/DELETE）
• 静态配置表（内容极少变动，且应用层已做缓存）
• 全文检索早期需求（MATCH() AGAINST() 在 MyISAM 中更成熟，但 InnoDB 现在也够用）
坑点很致命：服务器异常关机后，.MYI 索引文件极易损坏，REPAIR TABLE 不一定成功，且修复过程锁表。别在生产环境赌运气。
Memory 和 Archive 这类引擎怎么避坑
MEMORY 表看着快，但本质是把压力转嫁给内存和锁机制：
• 数据随 mysqld 重启全丢，别存任何不可再生的数据
• 只支持 CHAR/INT 等定长类型，VARCHAR 会被转成固定长度，浪费内存
• 默认表级锁，高并发写反而比 InnoDB 更卡ARCHIVE 就是单向压缩桶：
• 只支持 INSERT 和 SELECT，不能 UPDATE/DELETE，也不能建普通索引（只有自增主键）
• 适合埋进后台跑批处理的日志冷数据，别指望它响应实时查询
真正需要纠结引擎的时候，往往不是“选哪个好”，而是“为什么上一个表没用 InnoDB”。默认就用它，除非你清楚知道放弃事务、行锁、崩溃恢复换来的是什么代价。
