日志审计系统不推荐使用myisam，仅极少数完全只读、不复制、环境可控的遗留归档表可能适用；其count(*)快但精度低，全表扫描优势在带where/order by时消失，且易崩溃、不兼容复制与中间件，现代方案普遍采用innodb+列存组合。
日志审计系统并不“更倾向于”使用 MyISAM —— 这个说法本身容易误导。真实情况是：极少数遗留日志归档表会用 MyISAM，但前提是满足三个刚性条件：完全只读、不参与复制、环境绝对可控；否则就是埋雷。
MyISAM 的 COUNT(*) 和全表扫描快，真能加速日志查询？
快，但只在特定场景下成立，且代价隐蔽：
-
COUNT(*)确实毫秒返回——因为 MyISAM 直接从.MYI文件头读行数；InnoDB 需遍历索引或依赖采样估算（innodb_stats_method=sampled），但这是以牺牲统计精度换来的“快” - 全表扫描快，本质是省掉了 InnoDB 的 MVCC 版本链遍历和 undo log 查找开销；但一旦日志表有
WHERE time > ?或ORDER BY，这个优势就大幅缩水 - MyISAM 的
key_buffer_size只缓存索引，不缓存数据；日志审计常需查user_id、ip、action等多字段，频繁读.MYD文件会触发大量随机 IO，QPS 反而低于配置合理的innodb_buffer_pool_size
为什么有人误以为 MyISAM 适合日志审计？
常见误解来源和实际风险：
- 把“插入快”当成“审计快”：MyISAM 批量
INSERT确实快（无事务开销），但日志审计核心是SELECT，不是写入 - 忽略崩溃风险：日志系统常长期运行，断电或异常 kill 后，
.MYD和.MYI极易不同步，CHECK TABLE常报error: 134（记录头损坏），必须REPAIR TABLE——该操作锁整张表，审计服务中断 - 误信“压缩表节省空间”：用
myisampack压缩的表是只读的，但日志表若曾被写入（哪怕一次INSERT），就不再安全；且压缩后无法再加索引，后续查询灵活性归零
真正适合日志审计的方案，从来不是换引擎
现代日志审计系统已基本脱离 MyISAM，原因很实际：
- 日志写入不可回避：哪怕“归档表”，也常有补录、重跑、修正等操作；只要发生过任何写入，MyISAM 就失去只读前提
- 主从复制绕不开：审计数据常需同步到分析从库，而 MyISAM 表在
binlog_format=ROW下无法回放变更，Seconds_Behind_Master静默失真，SHOW SLAVE STATUS不报错但数据早已滞后 - 中间件兼容性差：
ProxySQL或ShardingSphere检测到 MyISAM 的SELECT无事务上下文，可能误判为强一致性需求，把查询路由到主库，反而拖垮核心业务 - 替代方案更成熟：日志明细走
InnoDB（配好innodb_buffer_pool_size和innodb_log_file_size），聚合层用ClickHouse或Doris，冷数据归档用Parquet + Trino—— 这些组合在吞吐、过滤、下钻上都远超 MyISAM 单表
MyISAM 在日志审计中的所谓“适用”，本质上是历史技术债务的残余；今天还主动选它，往往意味着没看清 REPAIR TABLE 锁表时监控告警失灵、auto_increment 重启跳变导致关联断裂、或者从库数据静默错位这些真实故障点。
