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% 空间。
真正麻烦的不是命令本身，而是迁移前没检查主键和索引定义 —— 一执行就报错，线上表又不敢随便停。
