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等参数强耦合——改了引擎却不调内存参数，等于给法拉利装拖拉机轮胎。
