MySQL存储引擎是表的底层执行内核，每张表必须绑定；InnoDB因支持事务、行级锁和崩溃恢复而成为安全首选，MyISAM仅适用于只读归档等极窄场景；迁移需注意主键、索引和空间变化。

MySQL存储引擎 是决定一张表怎么存数据、怎么建索引、怎么加锁、是否支持事务的底层机制。它不是“可选插件”，而是每张表必须绑定的执行内核——你建表时没显式指定，MySQL 就按默认规则给你配一个（2025 年默认是 InnoDB）。

怎么查当前表用的是什么引擎？

最直接的方式是看 SHOW CREATE TABLE 输出里的 ENGINE=xxx 字段：

SHOW CREATE TABLE users;

输出中会明确带出类似 ENGINE=InnoDB 或 ENGINE=MyISAM；也可以批量查所有表的引擎：

SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'your_db_name';

⚠️ 容易踩的坑：有些 DBA 会改全局默认引擎，但单表创建时若写了 ENGINE=MyISAM，就以表级声明为准——别只信配置文件。

为什么 InnoDB 几乎总是比 MyISAM 更安全？

核心在三件事：事务、行级锁、崩溃恢复。MyISAM 这三项全缺：

• MyISAM 写入时锁整张表 —— 一个 UPDATE 正在跑，所有 SELECT 和其他写操作都得排队等；
• InnoDB 只锁命中的行（前提是命中索引），并发读写互不干扰；
• MySQL 突然断电或 kill -9，MyISAM 表大概率损坏（.MYD 文件错位），而 InnoDB 靠 redo log 自动前滚恢复，数据不丢；
• InnoDB 支持 FOREIGN KEY，数据库层就能拦住脏数据；MyISAM 加了外键语法也不生效。

换句话说：只要业务里有“用户下单”“余额扣减”“状态流转”，就必须用 InnoDB —— 不是性能问题，是数据正确性底线。

MyISAM 哪些

场景真能用？别硬套

不是“不能用”，而是适用面极窄。真实可用的只剩两类：

• 只读归档表：比如日志汇总表，每天凌晨 ETL 生成一次，之后只供 SELECT COUNT(*) 或 GROUP BY 查询 —— MyISAM 的 COUNT(*) 直接读元数据，比 InnoDB 全表扫描快得多；
• 全文检索早期兼容需求：MySQL 5.6 以前 InnoDB 不支持 FULLTEXT，但如今已无此限制；现在真要全文搜索，该上 Elasticsearch，而不是靠 MyISAM 挺着。

⚠️ 注意：哪怕只是“偶尔 INSERT”，也别选 MyISAM。一次写入触发表锁，可能卡住几十个并发查询 —— 现代业务几乎无法容忍这种不确定性。

迁移 MyISAM 到 InnoDB 有哪些坑？

用 ALTER TABLE t ENGINE=InnoDB 很简单，但以下几点常被忽略：

• MyISAM 允许无主键，InnoDB 必须有主键 —— 如果原表没主键，迁移会失败，或自动加隐藏 row_id（不可控，且影响性能）；
• MyISAM 的 AUTO_INCREMENT 可以是联合索引的一部分，InnoDB 要求它必须是独立索引，或联合索引的最左列；
• MyISAM 的 FULLTEXT 索引迁过去后失效，需手动重建（MySQL 5.6+ 才支持 InnoDB 的全文索引）；
• 磁盘空间会明显增大：InnoDB 多存事务日志、聚簇结构、MVCC 版本链，通常比 MyISAM 占用多 30%–50% 空间。

真正麻烦的不是命令本身，而是迁移前没检查主键和索引定义 —— 一执行就报错，线上表又不敢随便停。