MySQL的写入效率在很大程度上取决于所选存储引擎的底层实现机制。不同引擎在数据存储格式、锁粒度、事务支持与日志策略上的差异，会直接导致同样的INSERT或UPDATE语句在不同配置下产生数量级的性能落差。要真正优化写入，不能只靠加索引或调缓冲区，而要先弄清楚引擎本身是怎么把数据落到磁盘的。
主流存储引擎的写入路径差异
InnoDB作为MySQL默认引擎，写入并不是直接改数据页，而是先写redo日志、再走缓冲池脏页刷新，并且开启双写缓冲防止半写问题。这种机制保障了事务的持久性与崩溃恢复能力，但在高吞吐写入时，redo日志的串行化写入与双写开销会成为瓶颈。每一次提交都要确保日志落盘，即使使用组提交，仍然受限于磁盘的fsync性能。
MyISAM则不使用事务，数据文件和索引文件分离，写入时以表级锁保护并直接追加到MYD文件。缺少了回滚段与redo的约束，顺序插入的速度通常明显快于InnoDB，尤其适合只读为主或批量导入后不再修改的报表数据。但表锁意味着并发写入会互相阻塞，且宕机后可能出现索引与数据不一致，必须借助repair恢复。
除这两者外，Archive引擎以行级压缩和只支持插入的特性，在日志归档类写入中表现极佳；Memory引擎把数据放内存，写入延迟极低但重启即丢。选择引擎时要权衡业务对一致性与速度的要求，而不是默认全用InnoDB。
针对InnoDB的写入参数调优
若业务必须使用InnoDB的事务与行锁，可通过调整若干参数缓解写入压力。将innodb_flush_log_at_trx_commit设为2，可把每次提交刷盘改为每秒刷盘，显著降低fsync次数，代价是极端宕机可能丢失一秒事务。同时调大innodb_log_file_size让redo有更大空间合并写入，减少检查点触发频率。
另一个关键是插入缓冲（change buffer）。对于非唯一二级索引的写入，InnoDB先把变更缓存在内存，等后续读或后台合并时才刷入磁盘。批量导入时若表含多个二级索引，可临时关闭唯一校验或延后建索引，让数据先以堆形式落入主键，再用ALTER TABLE添加索引，从而避免边写边维护B+树的随机IO。
下面示例展示批量导入前调整参数的典型做法：
-- 会话级放宽刷盘策略，仅用于可容忍少量丢失的离线导入 SET SESSION innodb_flush_log_at_trx_commit = 2; -- 先建无二级索引的表并导入 CREATE TABLE log_raw ( id BIGINT AUTO_INCREMENT PRIMARY KEY, msg VARCHAR(255), ts DATETIME ) ENGINE=InnoDB; -- 导入完成后一次性加索引 ALTER TABLE log_raw ADD INDEX idx_ts (ts);
用合适的引擎与架构分流写入
当单实例写入达到磁盘上限，可考虑按业务类型拆分引擎。将高频流水写入Archive或MyISAM暂存，再由定时任务清洗进InnoDB供查询；或采用多实例分库，让不同存储引擎各司其职。比如用户行为日志用Archive压缩存储，管理后台的关系数据用InnoDB保证一致。
在代码层也可通过批量提交减少引擎交互次数。使用多值INSERT替代单条提交，或利用LOAD DATA INFILE绕过SQL解析直接写文件，其速度往往数倍于普通INSERT。以下Python片段演示批量拼接与提交：
import pymysql
conn = pymysql.connect(host='127.0.0.1', user='root', password='test', db='demo')
cur = conn.cursor()
rows = [(f'msg_{i}', '2023-01-01 00:00:00') for i in range(1000)]
# 多值插入降低引擎调用频次
sql = 'INSERT INTO log_raw (msg, ts) VALUES ' + ','.join(cur.mogrify('(%s,%s)', r) for r in rows)
cur.execute(sql)
conn.commit()
最终优化写入效率的核心，是让存储引擎的特性匹配数据生命周期：临时高并发写用轻量引擎或参数妥协，核心业务留事务保障，再以批量与分流减少引擎不必要的开销。这样既不牺牲可靠性，也能把磁盘吞吐压到合理水位。