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; 看似简单，实则隐含三重开销：
