MyISAM仅支持表级锁，InnoDB默认行级锁但缺失索引时会退化为全表锁；读多写少可选MyISAM，事务场景必须用InnoDB；MEMORY适合临时缓存但不持久；ARCHIVE适用于只读冷数据；引擎选型需结合索引、查询模式与实际负载。
MyISAM 和 InnoDB 的锁机制差异直接影响并发写入性能
MyISAM 只支持表级锁，UPDATE 或 INSERT 时整个表被锁定，高并发写场景下容易排队阻塞；InnoDB 默认行级锁，只锁涉及的行，适合读写混合负载。但要注意：若 WHERE 条件未命中索引，InnoDB 会退化为锁全表（或锁索引范围），实际效果可能接近 MyISAM。
常见错误现象：SHOW PROCESSLIST 中大量线程处于 Locked 状态，且 State 显示 Waiting for table level lock —— 这基本可判定是 MyISAM 表，或 InnoDB 因缺失索引导致锁升级。
- 读多写少、无事务需求、全文检索为主 → MyISAM 仍有存在价值（但 MySQL 8.0 已移除其全文索引支持）
- 只要涉及转账、库存扣减、用户状态变更等需原子性操作 → 必须用 InnoDB
- 不要仅因“MyISAM 更快”就选它——这个“快”通常只出现在纯读 + 低并发 + 小数据量的基准测试中
MEMORY 引擎适合临时高速缓存，但重启即丢数据
MEMORY 引擎把表完全放在内存中，SELECT 极快，但所有数据不持久，MySQL 服务重启后表变空。它不支持 TEXT/BLOB 类型，且表大小受 max_heap_table_size 限制（默认 16MB）。
典型使用场景：作为中间结果集暂存，比如复杂报表生成前的聚合临时表；或配合 CREATE TEMPORARY TABLE ... ENGINE=MEMORY 做会话级加速。
- 误用
MEMORY存用户主表 → 数据丢失风险极高，线上严禁 - 忘记调大
max_heap_table_size→ 插入报错The table is full - 用
MEMORY替代 Redis 缓存 → 错误定位：它不提供过期、淘汰、分布式能力
ARCHIVE 引擎对日志类冷数据压缩率高，但只支持 INSERT 和 SELECT
ARCHIVE 引擎专为归档设计，使用 zlib 压缩，存储空间通常只有 InnoDB 的 1/5～1/10，但不支持索引（除主键外）、不支持 UPDATE/DELETE，查询只能全表扫描。
适用场景明确：审计日志、操作流水、传感器原始上报等“写一次、查极少、绝不改”的数据。一旦你发现某张表 SELECT COUNT(*) 耗时超过 1 秒，且业务上从不按条件查（比如从不带 WHERE create_time > '2023-01-01'），才考虑迁入 ARCHIVE。
- 在
ARCHIVE表上加INDEX→ 语法允许但无效，MySQL 忽略 - 用
ARCHIVE存订单明细并频繁按用户 ID 查询 → 性能反而比 InnoDB 差一个数量级 - 备份
ARCHIVE表时用mysqldump→ 没问题；但用物理拷贝.ARZ文件 → 不安全，必须停写或加锁
MySQL 8.0+ 的新引擎：了解 COLUMNSTORE（非官方）与 Clone 插件边界
MySQL 官方并未内置列式引擎，所谓 COLUMNSTORE 通常是 MariaDB 的特性或第三方插件（如 ClickHouse 引擎桥接）。MySQL 8.0 的 CLONE 插件用于快速克隆实例，不是存储引擎。混淆这两者会导致选型决策彻底跑偏。
真正影响性能的引擎选择，仍聚焦在 InnoDB（通用主力）、MyISAM（遗留/特殊读场景）、MEMORY（临时计算）、ARCHIVE（冷数据归档）四者之间。其他所谓“高性能引擎”，要么未进主线，要么依赖额外运维成本。
- 听说 “TokuDB 很快” 就想替换 InnoDB → TokuDB 已被 Percona 在 2021 年弃用，不再维护
- 看到 “列存加速分析” 就启用某个非标引擎 → 先确认是否已通过
SHOW ENGINES列出，否则大概率无法加载 - 用
ALTER TABLE ... ENGINE=InnoDB在线转换大表 → 必须预留足够磁盘空间（临时表+原表），且 MySQL 5.6+ 才支持 ALGORITHM=INPLACE
引擎不是性能银弹。一张没索引的 InnoDB 表，比有索引的 MyISAM 还慢；而一个设计混乱的 ARCHIVE 查询，可能拖垮整个连接池。选型之前，先看 EXPLAIN，再看 SHOW PROFILE，最后才动引擎。
