结论：写入极高频、纯追加、几乎不更新/删除、只按时间范围查的场景，myisam 或 archive 更合适；其余情况一律选 innodb。
日志表该用 MyISAM 还是 InnoDB？直接说结论：**写入极高频、纯追加、几乎不更新/删除、只按时间范围查的场景，MyISAM 或 ARCHIVE 更合适；其余情况一律选 InnoDB**。别被“InnoDB 默认”带偏——默认是为通用业务兜底，不是为日志优化。
MyISAM 在日志场景下的真实优势
MyISAM 对纯粹 INSERT-heavy 日志表确实有不可替代的轻量性：
- 没有事务开销：
redolog、undolog、doublewrite buffer全部跳过，单条 INSERT 的 I/O 路径短得多 - 表级锁在追加写时不构成瓶颈：因为新数据总插在末尾，不会触发锁等待（
INSERT DELAYED甚至能进一步缓冲） - 静态表格式（无
VARCHAR/TEXT）时，磁盘布局连续，顺序写性能接近裸文件 -
OPTIMIZE TABLE可回收碎片，对长期运行的日志表维护成本可控
但注意：MySQL 8.0 已移除系统表对 MyISAM 的依赖，用户表强行用它不会报错，但遇到权限变更、备份工具或监控插件时，可能因元数据兼容性出问题。
InnoDB 为什么在日志场景常被误用
很多人默认建日志表用 InnoDB，结果发现写入延迟高、Buffer Pool 被冷数据占满、磁盘空间涨得快——根本原因不是 InnoDB 本身差，而是它被当成了“普通表”来用：
- 每行 INSERT 都要写
ib_logfile+ 更新ibdata1或独立表空间，即使没事务也绕不开 -
innodb_buffer_pool_size被大量低热度日志页占据，挤占了业务热数据缓存 - 自增主键 + 时间递增插入导致 B+ 树右端持续分裂，产生写入热点和碎片
- 如果开了
innodb_file_per_table = OFF，删旧日志表根本释放不了磁盘空间
这不是引擎缺陷，是配置与使用方式没对齐场景。
ARCHIVE 引擎才是更干净的日志选项
比 MyISAM 更专一：它只为“写一次、查极少、压得死”的日志而生：
- 自动 zlib 压缩，实测存储空间仅为 InnoDB 的
1/4 ~ 1/10 - INSERT 极快，因为只追加、不索引、不缓存、不事务
- 不支持
UPDATE/DELETE/ORDER BY，从设计上杜绝误操作 - 唯一可用查询是
SELECT ... WHERE timestamp BETWEEN ...，全表扫描但压缩后 I/O 少
缺点也很明确：不能加索引，单条记录查询慢；不支持事务，崩溃恢复靠重放 binlog（需搭配 binlog_format = ROW）。
实际建表时的关键判断点
别纠结“哪个更好”，先问清楚这四件事：
- 是否需要
UPDATE或DELETE历史日志？→ 必须用 InnoDB（MyISAM 和 ARCHIVE 都不支持） - 查询是否只按时间范围（
WHERE created_at >= '2026-04-01'）？→ ARCHIVE 足够；若还要按状态、用户 ID 等字段查 → 得加索引 → 回头看 InnoDB - 日志保留周期多长？超 3 个月且写入量大 → ARCHIVE + 分区表（
PARTITION BY RANGE (TO_DAYS(created_at))）比 MyISAM 更省空间 - 是否已启用
binlog且格式为ROW？→ ARCHIVE 崩溃后可重建；否则优先 MyISAM（至少能REPAIR TABLE）
真正容易被忽略的是：ARCHIVE 表无法 ALTER TABLE ... ADD COLUMN，字段结构必须建表时定死。一旦业务埋点字段变多，改表就得导出再重建——这点比 MyISAM 还刚性。
