mysql存储引擎是决定表高并发能力、数据安全与查询性能的底层开关，选错会导致慢查询、锁表或数据不一致；必须用show engines和show create table等命令主动核查引擎类型，innodb是绝大多数业务的底线选择。
MySQL存储引擎不是“默认选InnoDB就完事”的配置项，而是决定一张表能不能扛住高并发、会不会丢数据、查得快不快的底层开关。选错一次，轻则慢查询频发，重则凌晨被叫醒处理锁表或数据不一致。
SHOW ENGINES 和 SHOW CREATE TABLE 是你每天该看两次的命令
很多人连自己库里有没有 MyISAM 表都不知道，更别说 Archive 或 Memory。别靠猜，直接查：
-
SHOW ENGINES看当前实例支持哪些引擎，DEFAULT那行才是真实默认值（MySQL 5.5+ 基本都是InnoDB） -
SHOW CREATE TABLE `order_log`查单表用的什么引擎——尤其要盯历史表，很多老系统建表时没写ENGINE=，结果沿用了旧版本默认（比如 MySQL 5.1 的MyISAM） -
SELECT TABLE_NAME, ENGINE FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'prod_db'批量扫库，导出后 grepMyISAM或MEMORY
注意：MEMORY 引擎表重启即空，MyISAM 在写入密集场景下会因表锁卡死整个表，这些都不是“只是性能差一点”的问题。
InnoDB 不是万能解药，但它是绝大多数业务的底线
如果你的业务涉及“必须同时成功或同时失败”的操作（比如扣库存+生成订单+写日志），InnoDB 是唯一合理选项。它靠 redo log 和 undo log 实现崩溃恢复与 MVCC，并发写入时只锁行，不锁整张表。
- 主键查询极快（聚簇索引，数据和主键一起存），但非主键查询可能回表，
WHERE status = 'paid'这种条件若没建二级索引，就是全表扫描 -
innodb_buffer_pool_size必须调大（建议设为物理内存的 70%~80%），否则大量磁盘 IO 会掩盖引擎本身的优势 - 不要在
InnoDB表里存超大TEXT字段并频繁查询——它会把大字段溢出到单独页，拖慢整体访问速度
MyISAM 只适合三类场景，其他时候请绕开
MyISAM 已被 MySQL 8.0 彻底移出系统表，官方明确标记为“legacy”。它只剩三个真实可用场景：
- 纯静态只读数据，比如省份字典表（
INSERT一生只有一次，SELECT每秒几千次） - 归档型日志表，且确认永不需事务、不需并发写、不需崩溃恢复（比如某业务的原始埋点快照，写完就只查不改）
- 需要全文索引且用的是 MySQL 5.6 以前的老版本（新版
InnoDB全文索引已追平甚至反超）
只要出现 INSERT ... ON DUPLICATE KEY UPDATE、REPLACE INTO 或任何事务控制语句，MyISAM 就会直接报错或行为异常——这不是兼容性问题，是能力缺失。
Archive 和 Memory 引擎不是“备选”，而是“特供”
ARCHIVE 只干一件事：高压缩比存日志，只支持 INSERT 和 SELECT，不支持索引、不支持事务、不支持 UPDATE/DELETE。它适合每天写 500 万条、一年查不到 10 次的审计流水。
-
MEMORY表所有数据在 RAM，SELECT极快，但实例重启即空，且不支持TEXT/BLOB；它只该用于临时中间计算（如CREATE TEMPORARY TABLE ... ENGINE=MEMORY），绝不能当缓存表或会话表用 - 用
MEMORY做缓存？不如直接上 Redis；用ARCHIVE存核心业务日志？先确认下游 ETL 工具是否真能解析它的压缩格式（有些旧版mysqldump会直接跳过）
真正容易被忽略的，是混合引擎带来的隐性成本：比如用 MyISAM 存日志表，又用 InnoDB 关联查询，MySQL 优化器可能放弃使用索引，或者执行计划突然变慢——引擎差异会影响 join 策略，这点连 EXPLAIN 都未必明说。
