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指标。
