Archive引擎是专为冷数据归档设计的存储引擎，支持zlib行级压缩与追加写入，压缩比高达8:1，不支持UPDATE/DELETE/索引（除隐式主键），适用于只写少查的历史数据场景。
Archive 引擎才是归档历史数据的更优解，InnoDB 和 MyISAM 压缩表都不是为“纯归档”场景设计的。
你如果真在考虑用 InnoDB 或 MyISAM 的压缩能力来存半年以上的登录日志、操作流水、采集上报等冷数据，大概率会踩进锁表、备份失败、查询卡死、空间没省多少的坑里。
为什么InnoDB压缩表不适合纯归档场景
InnoDB 支持 ROW_FORMAT=COMPRESSED 和 KEY_BLOCK_SIZE，但它本质仍是事务型引擎：要维护 redo log、undo log、B+树索引、MVCC 版本链。这些开销对只写不改的数据是冗余负担。
- 压缩比有限：文本类日志在
InnoDB下通常只压到原大小的 50%–70%，远不如Archive的 80%–90%（实测 40GB → 4GB） - 写入吞吐受锁和刷脏页影响：高并发插入时 buffer pool 和 flush 操作会成为瓶颈
- 备份麻烦：
mysqldump能导出，但大表导出耗时长、锁表久；xtrabackup支持热备，但压缩表的物理文件结构更复杂，恢复验证成本高 - 你没法关掉事务、关掉索引、关掉 MVCC —— 它不是为你“只写一次”的需求造的
MyISAM压缩表（myisampack）的问题更隐蔽
用 myisampack 工具生成的只读压缩表，确实能省空间、支持索引、单行可查，但它有三个硬伤：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 压缩后彻底不可修改：连
OPTIMIZE TABLE都不能执行，表损坏只能重建 - 不支持并发查询：MyISAM 压缩表是串行访问的，一个
SELECT就会阻塞其他所有查询，QPS 上不去 - 备份不可靠：
mysqldump对压缩表支持不稳定；物理拷贝需停服，且.MYI索引文件必须和.MYD严格配对，漏一个就打不开 - MySQL 8.0 已移除
myisampack的部分兼容性支持，新版本部署风险上升
Archive引擎才是真正为归档而生的“冷盘”
它不是“压缩版 MyISAM”，而是从设计上就放弃通用性，换来了极致归档效率：
- 写入路径极简：zlib 行级压缩 + 追加写，无索引维护、无事务日志、无缓冲池刷新压力
- 磁盘占用真实低：重复文本、JSON 日志、固定结构流水，压缩比常达 8:1 甚至更高
- 并发写安全：自带行级锁 + 专用写缓冲区，万级 INSERT/s 不抖动
- 查询虽慢但可控：全表扫描不可避免，但可通过
WHERE条件过滤（注意只能走主键或全字段匹配），配合分区（按月建表）可大幅缩短扫描范围 - 备份明确：不用
mysqldump，直接SELECT ... INTO OUTFILE或拷贝.ARZ文件即可，体积小、速度快
Archive不是万能的，但它的限制恰恰是优点
它不支持 UPDATE、DELETE、INDEX（除隐式主键外）、TRUNCATE，也不支持并行 SELECT——这些“缺点”其实是边界声明：你一旦选了 Archive，就等于承认这批数据是“写完即封存”的。
真正容易被忽略的是两点：第一，Archive 表无法被 mysqldump 自动识别和导出，脚本里漏掉它，归档表就等于没备份；第二，它的 SELECT 是阻塞式串行执行，如果有人跑了个没加 LIMIT 的全表统计，整个库的 Archive 查询都会排队等它结束。
