MyISAM在纯归档场景下因行数计数器、小索引文件、无事务开销及myisampack高压缩率而具边际优势，但仅限只INSERT、不更新、不care崩溃的静态场景，否则锁表、修复难、升级失效等风险陡增。
MyISAM在日志归档类业务中仍有零星使用，不是因为它“好”，而是因为某些极窄场景下它能用最小代价满足“只写一次、极少查询、不care崩溃”的硬性约束——但这种选择必须建立在对风险的清醒认知之上。
MyISAM在归档表上快在哪？
关键点不在绝对性能，而在轻量级设计带来的边际优势：
-
COUNT(*)不扫表：MyISAM 自带行数计数器，SELECT COUNT(*) FROM tbl是 O(1)，InnoDB 则需遍历索引（即使有主键） - 索引文件更小：无事务元数据、无 undo/redo 日志指针，
.MYI文件体积通常比 InnoDB 的.ibd小 20%～30% - INSERT 吞吐略高：省去事务开销和行锁管理，在单线程批量插入（如每小时 dump 一次日志）时延迟更低
- 压缩后空间节省明显：用
myisampack压缩后，静态归档表可减少约 60% 存储空间
为什么必须是「纯归档」才敢用？
所谓“纯归档”，是指这张表从创建起就满足以下全部条件：
- 只允许
INSERT，禁止任何UPDATE/DELETE/REPLACE - 应用层保证写入顺序与时间分区一致（例如按天建表：
sys_log_20261001），且永不跨表修改 - 查询极少，且几乎不带
WHERE条件（或仅靠主键查单条）；若需按时间范围查，应由上层服务聚合后走外部索引（如 Elasticsearch） - 接受服务器异常断电后该表报
crashed，并愿意手动执行myisamchk -r /path/to/tbl.MYI修复（注意：修复过程锁表，且失败率随损坏程度上升）
一旦其中任一条件松动——比如运营临时要求“删掉某条错误日志”或“补录一条漏报记录”，MyISAM 就立刻暴露出不可控缺陷。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
常见错误现象与误判
很多团队误以为“归档表读多写少”，就默认 MyISAM 更合适，结果在线上踩坑：
-
SHOW PROCESSLIST中大量线程卡在Waiting for table level lock：哪怕只是并发 INSERT，MyISAM 也会锁整张表，QPS 超过 5 就可能排队 - 凌晨定时任务执行
OPTIMIZE TABLE时阻塞所有查询：MyISAM 的OPTIMIZE实质是REPAIR + ANALYZE，锁表时间与表大小正相关 - MySQL 升级到 8.0 后全文检索失效：MySQL 8.0 已移除 MyISAM 的
MATCH() AGAINST()支持，而 InnoDB 的全文索引早已可用 - 监控发现
Table_locks_waited持续上涨，却归因为“慢查询”，实际是 MyISAM 表级锁争用
替代方案其实更稳
除非你正在维护一个已上线十年、不敢动引擎的老系统，否则现在有更好的归档路径：
- 用
ARCHIVE引擎：专为归档设计，zlib 压缩率更高（常达 InnoDB 的 1/5），只支持INSERT/SELECT，无锁表风险，且 MySQL 8.0 仍原生支持 - InnoDB + 分区表 +
ROW_FORMAT=COMPRESSED：配合innodb_file_per_table=ON，可实现接近 ARCHIVE 的压缩比，同时保留索引能力与事务安全 - 冷热分离：归档数据导出为 Parquet 或 ORC，存入对象存储（如 S3/OSS），用 Trino/Presto 查询——彻底脱离 MySQL 锁与引擎限制
真正容易被忽略的点是：MyISAM 的“快”永远绑定在“完全静态”前提下；而业务只要开始演进，这个前提就会第一个崩塌。选它，本质上是在用运维复杂度换初期几毫秒的 INSERT 延迟——这笔账，得算清楚。
