myisam在日志审计类表中几乎不值得考虑，因其缺乏事务支持、条件查询无优势、复制兼容性差、压缩后不可写、重启导致自增断裂、缓存机制低效，且现代审计需明细innodb+聚合引擎+冷数据归档的分层架构。
MyISAM 在日志审计类表中几乎不值得考虑，除非你正维护一个已停更、无复制、永不重启的只读归档库——这种场景在 2026 年已属极端例外。
MyISAM 的 COUNT(*) 快，但审计查询根本不是查总行数
很多人被 COUNT(*) 的毫秒响应误导：MyISAM 确实从 .MYI 文件头直接读计数，而 InnoDB 需遍历索引或依赖采样估算（innodb_stats_method=sampled）。但这只对“全表无条件统计”有效。
真实审计场景中，查询几乎都带条件：
-
WHERE event_time BETWEEN '2026-09-01' AND '2026-09-30'→ MyISAM 失去行数缓存优势，必须扫.MYD -
ORDER BY user_id, event_time LIMIT 100→ MyISAM 无法利用索引排序加速，因数据物理顺序与索引无关 - 需要
JOIN关联用户表或操作类型表 → MyISAM 缺乏事务一致性保障，中间状态可能被其他会话看到
所谓“插入快”和“压缩省空间”，在审计系统里全是反向代价
日志表看似只写不读，但审计系统实际存在补录、重跑、字段修正等写入行为。只要发生过一次 INSERT 或 UPDATE，MyISAM 就不再满足“纯只读”前提。
常见误操作及后果：
- 用
myisampack压缩后，表变成只读 —— 但日志系统无法接受“不能修正错误数据” - 压缩表无法再添加索引 —— 后续想按
ip或action加速查询？做不到 - MySQL 重启后，
AUTO_INCREMENT值重算 → 审计流水号跳变，关联分析断裂 -
key_buffer_size只缓存索引，不缓存数据 → 审计常需返回user_id、ip、detail等多字段，触发大量随机 IO，QPS 反低于配置合理的innodb_buffer_pool_size
主从复制和中间件会让 MyISAM 表静默失效
现代审计系统极少单点部署。一旦接入复制链路或代理层，MyISAM 就暴露致命兼容问题：
- 主库
binlog_format=ROW，从库改ENGINE=MyISAM→ 复制线程不报错，但Seconds_Behind_Master静默失真，数据早已不同步 -
ERROR 1594 (HY000): Relay log read failure常在 DDL 后出现，尤其ALTER TABLE ... ENGINE=MyISAM - ProxySQL 检测到 MyISAM 的
SELECT无事务上下文，可能误判为强一致需求，把本该打到从库的审计查询路由到主库，拖垮核心业务
真正可行的审计方案，从来不是靠换引擎压榨单表性能：明细走 InnoDB（配好 innodb_buffer_pool_size 和 innodb_log_file_size），聚合层用 ClickHouse 或 Doris，冷数据归档进 Parquet + Trino。MyISAM 的适用边界，如今只剩极个别未升级的离线报表快照，且必须有人每天手动 CHECK TABLE 和 REPAIR TABLE——这不是架构选型，是技术债看守。
