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，其实是配置没调好。比如：
启科网络商城系统由启科网络技术开发团队完全自主开发，使用国内最流行高效的PHP程序语言，并用小巧的MySql作为数据库服务器，并且使用Smarty引擎来分离网站程序与前端设计代码，让建立的网站可以自由制作个性化的页面。 系统使用标签作为数据调用格式，网站前台开发人员只要简单学习系统标签功能和使用方法，将标签设置在制作的HTML模板中进行对网站数据、内容、信息等的调用，即可建设出美观、个性的网站。
- 没建主键 → 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 指标。
