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 这三项全缺：
Pandas 配置文件报告生成器
下载
使用ydata-profiling（前身为pandas-profiling）生成全面的数据质量报告，包含相关性分析、缺失值模式和基数检测。导出交互式HTML仪表板和JSON摘要。
-
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% 空间。
真正麻烦的不是命令本身，而是迁移前没检查主键和索引定义 —— 一执行就报错，线上表又不敢随便停。
