执行 SHOW ENGINES; 查 SUPPORT 列，YES 表示可用，DEFAULT 表示当前默认（2026年绝大多数 MySQL 实例默认为 InnoDB），不可依赖文档或 information_schema.TABLES 中已有表的 ENGINE 字段。
怎么查当前MySQL支持哪些存储引擎
直接执行 SHOW ENGINES;，看 SUPPORT 列：值为 YES 表示可用，DEFAULT 表示当前默认（2026年绝大多数 MySQL 实例都是 InnoDB）。别依赖文档或记忆，不同版本、不同编译选项下可能禁用某些引擎（比如 Federated 常被关掉）。
常见误操作是只看 information_schema.TABLES 里的 ENGINE 字段，但那只是已有表的引擎，不是“系统能用什么”。真正选型前，必须先确认底层是否真的支持。
为什么 InnoDB 是默认且几乎必选的引擎
不是因为它“先进”，而是它解决了生产环境最痛的三个问题：事务原子性、并发写不卡死、数据崩了还能救回来。只要你的业务涉及“钱”“单”“库存”“状态流转”，就绕不开这三点。
-
START TRANSACTION; UPDATE ...; INSERT ...; COMMIT;—— 任意一步失败，全回滚，不会出现“扣了钱但没下单” - 两个用户同时改同一张订单的地址？
UPDATE orders SET addr=... WHERE order_id=123只锁这一行，不影响其他订单 - 服务器突然断电？重启后
InnoDB自动用redo log重做未刷盘的提交，用undo log回滚未完成的事务
MyISAM 虽然 SELECT COUNT(*) 快、建表快、磁盘占得少，但一旦写入过程中崩溃，表大概率损坏，只能 REPAIR TABLE（还未必修得好）—— 这在无人值守的线上服务里是不可接受的风险。
什么时候可以考虑非 InnoDB 引擎
不是“能不能用”，而是“有没有必要放弃事务和崩溃恢复来换一点性能或空间”。真实场景中，只有三类情况值得认真评估：
-
Archive：日志表、审计表、埋点数据表，只
INSERT+ 极低频SELECT，且对查询延迟不敏感。压缩率高（比 InnoDB 小 80%+），但不支持索引、不能UPDATE/DELETE -
MEMORY：纯临时中间表，比如 ETL 中的聚合缓存、报表预计算结果。重启即空，且
max_heap_table_size限制单表大小，超限会静默转成磁盘表（变成 MyISAM，性能断崖下跌） - MyISAM：仅限遗留系统迁移过渡期，或完全静态的配置表（如国家代码、币种字典），且确认应用层已做并发控制——新项目写死用 MyISAM，等于主动放弃数据库层的数据保护能力
注意：CREATE TABLE ... ENGINE=MyISAM 在 MySQL 8.0+ 已被标记为弃用，部分云厂商 RDS 默认禁用该语法。
建表时指定引擎的坑与细节
显式写 ENGINE=InnoDB 不是多此一举，而是防错关键。尤其当 DBA 修改过全局 default_storage_engine，或你连接的是旧版本从库（默认仍是 MyISAM）时，漏写会导致表建错引擎。
更隐蔽的问题是字符集和排序规则间接影响引擎行为：InnoDB 要求主键或唯一键字段不能是前缀索引（如 VARCHAR(255) 加 INDEX(col(10))），而 MyISAM 允许——如果迁移时没检查，建表会报错 ERROR 1170 (42000): BLOB/TEXT column 'xxx' used in key specification without a key length。
最后提醒一句：不要为了“全文检索快”选 MyISAM。MySQL 5.6+ 的 InnoDB 已支持 FTS（需 innodb_ft_enable_stopword=OFF 等配置），且能保证更新实时可见——MyISAM 的全文索引修改后要 REPAIR TABLE 才生效，线上根本没法用。
