存储引擎直接影响MySQL性能：InnoDB支持事务和行锁，适合OLTP；MyISAM仅表锁、无事务，适合只读场景；Memory、Archive、Blackhole各具特定用途；引擎选择需按表评估并动态调整。
存储引擎直接影响 MySQL 的性能表现，不同引擎在读写速度、并发能力、事务支持、锁机制和资源占用等方面差异显著。
InnoDB：高并发与事务场景的首选
InnoDB 是 MySQL 默认存储引擎，支持行级锁、ACID 事务、外键约束和崩溃恢复。它通过缓冲池（Buffer Pool）缓存数据和索引，大幅减少磁盘 I/O；同时采用聚簇索引组织数据，主键查询极快。但写入时需维护事务日志（redo log）和回滚段（undo log），对高写入负载可能带来额外开销。
- 适合 OLTP 类应用（如电商订单、用户账户）
- 大量更新/删除操作时注意长事务和锁等待问题
- 合理设置 innodb_buffer_pool_size（通常为物理内存的 50%–75%）
MyISAM：读多写少、轻量级场景的备选
MyISAM 不支持事务和行锁，只提供表级锁，因此并发写入能力弱，但其结构简单、索引紧凑，全表扫描和 COUNT(*) 查询（无 WHERE 条件）比 InnoDB 更快。它使用独立的数据文件（.MYD）和索引文件（.MYI），便于直接拷贝迁移。
- 适用于静态报表、日志归档、只读或极少更新的配置表
- 崩溃后无法保证数据一致性，恢复依赖 myisamchk
- 不推荐在新项目中使用，MySQL 8.0 已移除对它的默认支持
其他引擎的适用边界
Memory 引擎将所有数据保存在内存中，读写极快，但服务重启即丢失数据，适合临时缓存或中间计算结果；Archive 针对归档设计，高压缩比、仅支持 INSERT 和 SELECT，适合历史日志类冷数据；Blackhole 则用于复制过滤或审计日志转发，不存数据但记录 binlog。
- 选择非默认引擎前，确认业务是否真正需要其特性
- 混合使用多引擎时，注意跨引擎 JOIN 性能下降和事务隔离限制
- 监控 information_schema.ENGINES 和 SHOW TABLE STATUS 查看实际引擎分布
引擎选择不是一劳永逸
同一张表在生命周期中可能面临不同负载特征：初期数据量小可选 MyISAM 快速上线，后期并发增长必须迁移到 InnoDB；而归档表达到阈值后，又可转为 Archive 减少空间占用。迁移可通过 ALTER TABLE t ENGINE=InnoDB 完成，但大表需评估锁表时间和磁盘空间。
- 定期用 performance_schema 分析锁等待、I/O 等待和语句执行模式
- 避免“一刀切”式引擎配置，按表维度精细化评估
- 测试环境务必模拟真实读写比例与并发压力验证效果
