myisam表级锁致高并发写阻塞，innodb行级锁+mvcc更优但需合理主键；archive适合只插入冷数据；innodb压缩可降i/o但增cpu开销；临时表引擎选型与配置直接影响排序性能。
MyISAM 和 InnoDB 对写入吞吐的影响差异明显
MyISAM 表级锁在高并发 INSERT/UPDATE 场景下会严重阻塞，尤其当有长事务或批量写入时，Waiting for table metadata lock 错误频发；InnoDB 行级锁 + MVCC 能更好支撑并发写，但前提是主键设计合理、避免热点更新。若业务以「大量顺序写 + 几乎不更新」为主（如日志归档），MyISAM 的写入速度可能略高，但缺失 crash-safe 保障，MySQL 8.0 已默认禁用 MyISAM 系统表。
实操建议：
- 除非遗留系统强依赖全文索引（MyISAM 的
FULLTEXT）或压缩表（myisampack），否则一律选InnoDB - 避免在
InnoDB中使用 UUID 或随机字符串作主键——会导致聚簇索引频繁页分裂，innodb_page_size默认 16KB 下写放大显著 - 批量插入时，用
INSERT INTO ... VALUES (...), (...), (...)而非多条单行语句，减少事务开销和 redo log 刷盘次数
何时考虑 Archive 引擎做冷数据存储
ARCHIVE 引擎专为「只插入、极少查询、高压缩比」场景设计，行存 + zlib 压缩，磁盘占用通常只有 InnoDB 的 10%–20%。但它不支持索引（除自增 id）、不支持事务、查询只能全表扫描，且 SELECT 会解压整行——意味着单行查询延迟不可控。
适用边界很窄：
- 已归档的订单/日志明细，按时间范围查（用
WHERE date BETWEEN ...）且能接受秒级响应 - 表大小 >100GB，且 95%+ 访问来自离线分析（可配合
SELECT ... INTO OUTFILE导出后处理） - 确认业务层已做好「Archive 表只写不删」约束——
DELETE会触发全表重建，极其缓慢
Compressed Row Format 对 I/O 效率的真实影响
InnoDB 支持 ROW_FORMAT=COMPRESSED（需 KEY_BLOCK_SIZE 配合），本质是页级 zlib 压缩。它降低磁盘 I/O 次数，但增加 CPU 解压开销；是否划算取决于硬件瓶颈：SSD 场景下，若 CPU 闲置而磁盘队列常满（iostat -x 显示 %util >90），开启压缩往往提升吞吐；反之在高并发 OLTP 中，CPU 成为瓶颈时可能反而降速。
关键限制：
- 仅对 BLOB/TEXT/LONG VARCHAR 等大字段压缩效果明显；纯 INT/VARCHAR(32) 类型表压缩率常低于 10%
-
KEY_BLOCK_SIZE=8要求innodb_file_per_table=ON且文件系统块大小 ≥4KB - 压缩失败时（如页内碎片过多），InnoDB 自动降级为未压缩页，但不会报错——需定期用
INFORMATION_SCHEMA.INNODB_SYS_TABLES检查ZIP_PAGE_COUNT是否为 0
临时表引擎选择直接影响 GROUP BY / ORDER BY 性能
MySQL 内部临时表默认用 MEMORY 引擎（哈希索引、无磁盘 I/O），但受 tmp_table_size 和 max_heap_table_size 限制。一旦结果集超限，自动转成 InnoDB 临时表，产生磁盘排序（Using temporary; Using filesort），性能断崖下跌。
优化方向很直接：
- 调大
tmp_table_size和max_heap_table_size（需两者一致），但注意全局内存占用——每个连接都可能创建临时表 - 避免
SELECT *后再GROUP BY，只SELECT必需字段 + 聚合列，减小临时表体积 - 对大表
ORDER BY，优先走索引覆盖（EXPLAIN显示Extra: Using index），而非依赖临时表排序
innodb_log_file_size 与写入模式的匹配——日志文件太小（如默认 48MB）会导致频繁 checkpoint，拖慢批量导入；太大又延长崩溃恢复时间。没有银弹配置，得结合 SHOW ENGINE INNODB STATUS 里的 Log sequence number 增速和 Checkpoint age 波动来调优。
