mysql中MyISAM与InnoDB存储引擎的性能对比

MyISAM适合只读或低并发写入场景，SELECT性能比InnoDB高10%–30%，但表级锁使其在并发写入时成为瓶颈；InnoDB是默认推荐引擎，支持事务、行级锁等核心功能，合理配置下性能更优。

MyISAM 适合只读或低并发写入的场景

MyISAM 在纯读取密集型业务（比如日志归档表、报表维度表）中，SELECT 性能通常比 InnoDB 高 10%–30%，因为它没有事务开销、不维护行级锁、索引结构更紧凑。但一旦出现 INSERT 或 UPDATE，尤其并发稍高时，MyISAM 的表级锁会立刻成为瓶颈——整张表被锁住，后续所有读写都排队。

常见错误现象：SHOW PROCESSLIST 中大

量线程卡在 Waiting for table level lock；INSERT 延迟突增，而 SELECT 也变慢。

• 仅用于静态数据（如国家代码表、配置字典），且确认永不需事务或外键
• 避免在有定时任务批量写入的表上用 MyISAM，哪怕只是 INSERT ... SELECT
• REPAIR TABLE 和 OPTIMIZE TABLE 会锁表，线上慎用

InnoDB 是默认且推荐的通用引擎

InnoDB 支持事务、行级锁、外键、崩溃恢复，这些不是“高级功能”，而是现代 Web 应用的基础设施。它的写性能在多数场景下反而优于 MyISAM，尤其当写操作带主键或唯一索引更新时——InnoDB 的聚簇索引让数据物理顺序与主键一致，减少随机 I/O。

性能关键点：

• 默认开启 innodb_flush_log_at_trx_commit=1，保证事务持久性，但会牺牲一点吞吐；若允许短暂丢失最近 1 秒事务，可设为 2
• innodb_buffer_pool_size 必须占物理内存 50%–75%，否则大量磁盘读会让性能断崖下跌
• 大字段（TEXT/BLOB）超过 768 字节会溢出到独立页，影响主键查询效率，应考虑拆表或压缩

不要用 MyISAM 躲避 InnoDB 的配置问题

很多人把 INSERT 慢、UPDATE 卡归咎于 InnoDB，其实是配置没调好。比如：

• 没建主键 → InnoDB 自动生成隐藏 row_id，但二级索引回表变慢，且无法利用聚簇优势
• innodb_log_file_size 过小（如默认 48MB）→ 频繁刷 log，触发 checkpoint 停顿
• 用 UUID 做主键 → 插入完全随机，页分裂严重，INSERT 吞吐骤降 50%+

真实压测中，调优后的 InnoDB 在混合读写（QPS 2000+）下仍稳定，而同配置 MyISAM 在写入并发 >50 时就出现锁队列堆积。

迁移 MyISAM 到 InnoDB 的实操注意点

直接 ALTER TABLE t ENGINE=InnoDB 在大表上可能锁表数小时，且生成巨大临时文件。生产环境务必分步操作：

CREATE TABLE t_new LIKE t;
ALTER TABLE t_new ENGINE=InnoDB;
INSERT INTO t_new SELECT * FROM t;
RENAME TABLE t TO t_old, t_new TO t;

迁移后必须验证：

• 检查 SHOW CREATE TABLE t 是否含 ENGINE=InnoDB，而非只看 SHOW TABLE STATUS 的模糊输出
• 确认外键约束是否生效：INSERT 违反外键时是否报错 ERROR 1452 (HY000)，而不是静默忽略
• 对比 SELECT COUNT(*) 结果，MyISAM 的计数是缓存值，InnoDB 是实时扫描，结果应一致

真正难的不是引擎切换，而是清理历史遗留的 MyISAM 表依赖——比如某些老脚本硬编码了 MYISAM 特有语法（INSERT DELAYED），或监控工具只认 MyISAM 的 Key_read_requests 指标。