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，最后才动引擎。
