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 日志表，结果发现并没快多少，甚至更慢——大概率踩了下面这些坑：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

• 表里有 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 的廉价替代品来用。