日志归档应优先选用InnoDB配时间分区，ARCHIVE仅适用于写完即弃且零查询的极端场景，MyISAM因表锁、无事务、易损坏等缺陷在日志场景中应避免使用。
日志归档场景下，优先选 InnoDB（配时间分区），ARCHIVE 仅在满足极窄条件时可考虑，MyISAM 基本不该出现。
ARCHIVE 引擎只适合“写完就扔、几乎不查”的归档
ARCHIVE 表用 zlib 压缩每行，写入快、体积小，但代价是：只支持 INSERT 和 SELECT，没有索引（除隐式主键外），WHERE 条件必然触发全表扫描。实际中极少有日志真的一次写入、零查询——哪怕只是“查某天 ERROR 日志”，它就扛不住。
- 常见错误现象：
SELECT * FROM log_archive WHERE dt = '2026-08-01' AND level = 'ERROR'执行超慢，EXPLAIN显示type: ALL - 备份被跳过：
mysqldump默认忽略ARCHIVE表，必须手动用SELECT INTO OUTFILE或拷.ARZ文件 - 不支持事务、无崩溃恢复能力，断电后文件可能损坏且无法自动修复
MyISAM 在日志场景下是危险选项
MyISAM 虽然支持索引、能加速简单范围查询，但它表级锁 + 无事务 + 易损坏的组合，在日志持续写入场景下极易出问题。尤其当后台定时任务批量 INSERT 时，一个长查询或锁等待就能卡住所有日志写入。
- 锁机制反效果：
INSERT INTO log_myisam ...会锁整张表，后续SELECT或其他INSERT全部排队 - 崩溃风险高：服务器异常重启后，
.MYD文件大概率损坏，REPAIR TABLE不保证数据完整，且需停服执行 - MySQL 8.0+ 多数发行版已默认禁用 MyISAM 插件，
CREATE TABLE ... ENGINE=MyISAM可能直接报错Unknown storage engine 'MyISAM'
InnoDB + 分区是生产环境日志归档的合理解法
用 InnoDB 配合按时间字段（如 dt 或 created_at）做 RANGE 或 LIST 分区，既能保证写入并发性、事务安全和自动崩溃恢复，又能通过分区裁剪把查询限制在少数几个分区里，性能接近专用时序引擎。
- 必须建好索引：
dt字段要加索引，否则分区裁剪无效；高频查询字段（如level、service_name）建议建联合索引 - 注意
AUTO_INCREMENT：如果靠自增主键做唯一标识，确保它和分区键无强耦合，避免插入热点 - 清理旧数据更安全：
ALTER TABLE log_innodb DROP PARTITION p202501是毫秒级操作，比DELETE FROM ... WHERE dt < '2025-01-01'快且不锁表 - 备份兼容性好：
mysqldump、mysqlpump、物理备份工具（如 xtrabackup）都原生支持
真正需要压到极致存储空间且确认永不查细节时，才考虑 ARCHIVE；而 MyISAM 已不是“性能取舍”，是运维风险和版本兼容性问题。InnoDB 的配置成本并不高，但省下的 DBA 救火时间、数据一致性保障和未来扩展余地，远超那点磁盘节省。
