sql写入放大主要源于索引维护和事务日志记录，表现为每条dml操作需同步更新所有相关索引并生成wal日志，索引数量、宽度、类型及事务粒度共同加剧写入负担。
SQL写入放大主要源于索引维护和事务日志记录。每条INSERT/UPDATE/DELETE操作不仅写数据页，还要同步更新所有相关索引，并生成对应WAL（Write-Ahead Logging）日志。索引越多、字段越宽、更新越频繁，写入量就越大。
索引数量直接影响日志体积
每个B+树索引在数据变更时都需要独立写入日志条目：包括索引页分裂、键值插入/删除、父节点调整等。例如一张表有5个二级索引，执行1次单行INSERT，底层可能触发6次物理写（1次聚簇索引 + 5次二级索引），每写一次都产生日志记录。
- 复合索引比多个单列索引更节省日志——避免重复记录相同前导列的变更
- 唯一索引在INSERT时需额外做duplicate check，失败回滚也会写日志
- 函数索引或表达式索引在UPDATE涉及基础列时，即使表达式结果未变，仍会重算并写日志
索引字段宽度加剧写入负担
索引键越长，单次写入的日志字节数越多。比如VARCHAR(2000)字段参与索引，即使实际只存10字节，InnoDB仍按最大可能长度预留空间并记录完整键值到日志中（尤其在ROW格式下）。
- 避免用TEXT、JSON、长字符串建索引；优先使用前缀索引（如INDEX(col(64))）
- 对UUID类字段，考虑转为BIN(16)存储 + 索引，可减少约75%索引空间与日志量
- 时间戳+自增ID组合做联合主键时，比单纯UUID主键写入压力低一个数量级
事务粒度与批量操作的影响
小事务高频提交会导致日志频繁刷盘（fsync），而大事务虽减少提交次数，但单次日志量剧增、锁持有时间拉长、回滚段膨胀。关键在于平衡。
- 将1000次单行INSERT合并为1条多值INSERT，日志量通常可降60%以上（减少parse/plan/commit开销）
- UPDATE时尽量只改必要字段，避免SET col1=col1, col2=new_val（无意义赋值仍触发索引更新）
- 对批量导入场景，临时禁用非必要索引（ALTER TABLE ... DISABLE KEYS），导入完成后再重建
日志格式与复制设置不可忽视
binlog_format=ROW时，每行变更都完整记录新旧值，配合多索引会显著放大日志；STATEMENT格式虽日志小，但有复制不安全风险；MIXED是折中方案。
- 确认是否开启binlog_row_image=FULL（默认）；若业务允许，可设为MINIMAL，仅记录变更列和主键
- 从库延迟高时，检查是否因主库日志写入过载导致I/O瓶颈，而非单纯网络或SQL线程问题
- 使用pt-table-checksum等工具验证主从一致性时，注意其自身会引入额外索引扫描和日志写入
写入放大不是孤立问题，它把索引设计、事务习惯、日志配置、存储引擎特性全串在一起。优化时先看慢写入是否真由索引驱动，再逐层收紧——删冗余索引比调参数见效更快。
