MyISAM适合纯追加型日志表，因其无事务、无行锁、无redo/undo日志，INSERT直接落盘且无索引维护开销；但需满足静态表结构、无VARCHAR/TEXT、正确配置myisam_recover_options等前提，否则性能不升反降。
MyISAM 适合纯追加型日志表，核心就一条：它跳过了所有事务和行锁开销，INSERT 路径极短。但这不等于“随便用”，得满足几个硬条件——否则写入快不了，还可能丢数据。
MyISAM 的 INSERT 为什么比 InnoDB 快得多
不是 MyISAM “优化得好”，而是它根本没做 InnoDB 那些事：
-
redolog、undolog、doublewrite buffer全部不存在，单条INSERT直接落盘（或进 OS page cache） - 没有 B+ 树索引维护开销：如果日志表只按时间范围查、且主键/索引是自增时间戳，InnoDB 的右端分裂和页分裂会持续拖慢写入；MyISAM 默认用静态表格式，顺序追加就是线性写
- 表级锁在纯追加场景下不卡住：只要中间没
DELETE过，新数据永远插在文件末尾，INSERT和SELECT可并发（文档明确写的concurrent inserts）
必须满足的三个前提，否则优势归零
很多人建了 MyISAM 日志表，结果发现并没快多少，甚至更慢——大概率踩了下面这些坑：
- 表里有
VARCHAR或TEXT字段：破坏静态表结构，导致磁盘布局碎片化，顺序写性能断崖下跌 - 开了
DELAY_KEY_WRITE = ON却忘了配myisam_recover_options：崩溃后索引可能损坏，SELECT报错或返回脏数据 - MySQL 版本 ≥ 8.0 且用了权限变更/备份工具：部分工具（如
mysqldump --single-transaction）默认跳过 MyISAM 表，或元数据读取失败，监控插件也可能报Unknown engine 'MyISAM'
对比 InnoDB 日志表常见的误配置
用 InnoDB 做日志表却没调优，反而比 MyISAM 慢，常见原因：
-
innodb_buffer_pool_size被日志冷数据占满，挤掉业务热数据缓存 -
innodb_file_per_table = OFF：删旧日志表后ibdata1不释放空间，磁盘越用越大 - 没关
innodb_doublewrite或innodb_flush_log_at_trx_commit = 1：每条 INSERT 都强制刷盘，I/O 成瓶颈 - 主键不是单调递增（比如 UUID）：B+ 树频繁分裂 + 随机写，写入吞吐直接腰斩
真正要发挥 MyISAM 在日志场景的优势，得接受它不支持事务、崩溃不可恢复、无行锁这些事实——不是技术落后，而是设计取舍。一旦业务要求“不能丢一行日志”或“要按用户 ID 快速删旧数据”，MyISAM 就该立刻换掉。最危险的不是选错引擎，是把 MyISAM 当成 InnoDB 的廉价替代品来用。
