执行 SHOW ENGINES; 查 SUPPORT 列为 YES 的引擎，DEFAULT 行即默认引擎；也可用 SHOW VARIABLES LIKE '%storage_engine%'; 查 default_storage_engine 值。
怎么查当前支持哪些引擎，以及哪个是默认的
直接连上 MySQL 执行 SHOW ENGINES;，看 SUPPORT 列：值为 YES 表示可用，DEFAULT 那一行就是当前默认引擎。2026 年绝大多数生产环境用的是 InnoDB，但别猜——必须确认，尤其老系统或云托管实例可能被改过。
另一个快捷方式是查变量：SHOW VARIABLES LIKE '%storage_engine%';，返回的 default_storage_engine 值就是建表不写 ENGINE=... 时自动套用的那个。
- 如果
SHOW ENGINES;里InnoDB显示NO，说明它被禁用了（比如启动参数里写了--skip-innodb），此时哪怕建表指定ENGINE=InnoDB也会报错Unknown storage engine 'InnoDB' -
MyISAM几乎总是YES，但它在 MySQL 8.0+ 中已标记为“deprecated”，未来版本会移除，新项目别再主动选它
建表时不写 ENGINE=，到底用谁？
取决于服务器级默认值，不是数据库或用户级配置。也就是说，同一个 MySQL 实例里，所有没显式声明引擎的表，都用同一个默认引擎。
这个默认值可以在启动时通过 default-storage-engine=innodb 设置，也能运行时动态改（需 SUPER 权限）：SET GLOBAL default_storage_engine = 'InnoDB';。但注意：该设置只影响后续新建的表，已有表不受影响。
- MySQL 5.5 及以后版本，默认确实是
InnoDB；但如果你接手的是迁移过来的老库，或者用的是某些定制版 MySQL（如阿里云 PolarDB 兼容模式早期版本），仍有可能默认是MyISAM - 临时表（
CREATE TEMPORARY TABLE）有自己的默认行为：即使全局设了InnoDB，临时表仍可能回退到MEMORY引擎（尤其当没指定ENGINE且数据量小），这点容易被忽略
什么场景下还可能被迫用 MyISAM
基本没有正当理由。现在还在用 MyISAM 的，大多是历史包袱：比如某张日志表当年为了全文索引（FULLTEXT）选了它，而当时 InnoDB 还不支持全文索引（MySQL 5.6 才加）。
但这个理由在 2026 年已经失效：InnoDB 早支持 FULLTEXT，且支持事务、行锁、崩溃恢复——MyISAM 剩下的唯一“优势”是读取极轻量级表时略快几微秒，这在真实业务链路里根本测不出来。
- 如果看到
MyISAM表正在被频繁INSERT+SELECT，大概率会遇到表级锁阻塞：一个慢查询把整张表锁住，后面所有写都排队 -
REPAIR TABLE或myisamchk修复损坏表的操作，在InnoDB里完全不需要——它的崩溃恢复是自动的，靠redo log和undo log完成
想换引擎？ALTERTABLE ENGINE=… 有啥风险
执行 ALTER TABLE t1 ENGINE=InnoDB; 看似简单，实际是重建整张表：MySQL 会拷贝数据、重建索引、重写聚簇索引结构。期间表会被锁（InnoDB 是在线 DDL，但仍有短暂的元数据锁等待期；MyISAM 则全程锁表）。
大表操作前必须评估：磁盘空间是否够（临时需要 2 倍原表大小）、执行时间是否在维护窗口内、主从延迟是否会因此拉大。
- 如果原表有
FULLTEXT索引，ALTER后需要手动重建：ALTER TABLE t1 DROP INDEX ft_idx; ALTER TABLE t1 ADD FULLTEXT INDEX ft_idx(col); -
MEMORY表转InnoDB时，要注意原来允许NULL的字段在InnoDB里可能因外键或约束变严格，导致转换失败 - 最隐蔽的坑：某些监控工具或备份脚本硬编码了引擎类型判断逻辑，换完引擎后可能误判表状态，建议同步更新配套工具
真正要纠结引擎选择的地方，其实不在 InnoDB 和 MyISAM 之间，而在要不要用 ARCHIVE 存归档日志、要不要用 CSV 做中间交换、或者上 RocksDB 变体应对超大写入吞吐——但这些都不是“选错就崩”的问题，而是“用对了才省事”的问题。
