MySQL存储引擎决定数据存储、读取、锁定及崩溃恢复机制；InnoDB是95%场景首选，支持事务、行级锁和崩溃恢复，MyISAM仅适用于纯只读且无并发写需求的特殊情况。
MySQL 存储引擎就是决定数据“怎么存、怎么读、怎么锁、断电后能不能找回来”的底层机制——选错引擎，轻则 COUNT(*) 慢三倍，重则并发更新丢数据、崩溃后修表一整天。
怎么查当前用的是什么引擎
别猜，直接查。最常用两种方式：
-
SHOW TABLE STATUS LIKE 'your_table_name';→ 看Engine列值 -
SHOW CREATE TABLE your_table_name;→ 结果里明确写着ENGINE=InnoDB这类字样 - 想看全局支持哪些？
SHOW ENGINES;，重点关注Support列是YES还是DEFAULT
注意：SHOW VARIABLES LIKE 'have%'; 已过时，MySQL 8.0+ 中多数已被弃用，别依赖它判断引擎可用性。
InnoDB 和 MyISAM 到底该选谁
95% 的新表应该无脑选 InnoDB，除非你确认满足以下全部条件：纯只读、没并发写、不需要事务、不怕断电丢数据、且 SELECT COUNT(*) 频繁到真成瓶颈。
-
InnoDB：支持事务（BEGIN/COMMIT）、行级锁（并发写不卡全表）、外键、崩溃可恢复（靠ib_logfile*重做日志）。但COUNT(*)要扫索引，没 MyISAM 快；不支持全文索引（MySQL 5.6+ 已支持，但默认仍不如专用引擎） -
MyISAM：表级锁（一个UPDATE就堵住所有写），不支持事务（UPDATE中断=部分生效，无法回滚），崩溃后易损坏（得靠REPAIR TABLE，还可能丢数据）。优点只有：COUNT(*)极快（自己记着数）、全文索引老而稳、磁盘占用略小
真实踩坑案例：某日志归档表用 MyISAM，凌晨批量 INSERT 时服务器断电，第二天发现 .MYD 文件损坏，REPAIR TABLE 失败，丢了 6 小时数据。
改引擎不是 ALTER TABLE 一下就完事
ALTER TABLE t ENGINE=InnoDB; 看似简单，实则隐含三重开销：
- 全表重建：复制数据 + 重建索引，期间表不可写（或仅可读，取决于 MySQL 版本和
ALGORITHM参数） - 锁等待风险：如果表上有长事务或未提交的 DML，
ALTER会卡在 metadata lock，连SHOW PROCESSLIST都能看到Waiting for table metadata lock - 空间翻倍：重建过程中，旧文件不删，新文件已写，磁盘必须预留 ≥2 倍原表大小
生产环境务必加 ALGORITHM=INPLACE（5.6+ 支持）并配合 LOCK=NONE（需满足条件，如无全文索引、主键未改等），否则默认是 COPY 算法，停机时间不可控。
Memory 引擎不是“缓存表”的万能解
MEMORY 表数据全在内存，SELECT 极快，但它不是 Redis 替代品：
- 重启 MySQL 服务 = 全表清空，没持久化机制
- 默认最大内存限制是
max_heap_table_size（通常 16MB），超限插入直接报错The table is full - 只支持
HASH（等值查询快）和B-TREE索引，但VARCHAR会被转成固定长度CHAR，浪费内存 - 不支持
TEXT、BLOB、自增主键（除非设为NOT NULL）
它真正适合的场景只有一个：临时中间结果集，比如大表 JOIN 后的聚合结果暂存，生命周期严格绑定于当前会话或脚本执行期。
最常被忽略的一点：存储引擎不是孤立配置项，它和 innodb_buffer_pool_size、key_buffer_size（MyISAM 专用）、tmp_table_size 等参数强耦合——改了引擎却不调内存参数，等于给法拉利装拖拉机轮胎。
