InnoDB页大小不可运行时调整，缩小页大小不能缓解写入放大；页压缩（需innodb_file_per_table=ON）可降低写入量10%~30%；真正有效手段包括关闭doublewrite（需硬件支持）、调低持久性参数、启用change buffer、批量写入等，并需三层监控验证。
innodb_page_size 调整不能缓解写入放大
MySQL 启动后 innodb_page_size 就不可更改，且默认 16KB 是硬编码在 InnoDB 存储引擎底层的。试图通过修改配置重启来“缩小页大小”以降低写入放大，实际会失败并报错 Invalid argument —— 因为页大小只允许在初始化实例时指定（--innodb-page-size=4k|8k|16k），且 4KB/8KB 仅支持特定版本（如 MySQL 5.7.20+，且不兼容所有功能，比如压缩表和部分 DDL）。
更关键的是：即使强行用小页初始化，SSD 层面的写入放大（如 256KB 擦除单元）和 InnoDB 的 Double Write Buffer、Change Buffer 合并行为并不会因此减少；反而可能因页分裂更频繁、缓存命中率下降，导致逻辑写次数上升，物理写入量不降反增。
innodb_file_per_table=ON + page_compression 有真实收益
启用页压缩（ROW_FORMAT=COMPRESSED + KEY_BLOCK_SIZE）确实能降低磁盘写入量，但前提是数据可压缩性强（如文本、JSON、日志类字段），且必须配合 innodb_file_per_table=ON（默认已开启）。
实操要点：
-
KEY_BLOCK_SIZE设为 8 或 4（单位 KB），对应压缩后页目标大小；值越小，压缩率越高，但 CPU 开销越大，且可能触发更多页分裂 - 压缩只对新写入或
ALTER TABLE ... REBUILD后的数据生效，已有数据需显式重建：ALTER TABLE t1 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8; - 监控是否真正压缩成功：查
INFORMATION_SCHEMA.INNODB_CMP表，看compress_ops和compress_ops_ok是否接近（差值大说明压缩失败率高） - 注意：压缩页仍按 16KB 逻辑页管理，Redo Log、Undo Log、Binlog 不压缩，所以写入放大降低有限（通常 10%~30%，非数量级改善）
真正有效的写入放大抑制手段
页压缩只是表层优化，InnoDB 写入放大的主因是多层冗余写（Redo、Double Write、Binlog、Change Buffer 合并、B+ 树分裂）。要实质性压降，得直击这些环节：
- 关闭 Double Write Buffer：
SET GLOBAL innodb_doublewrite = OFF（仅限 MySQL 8.0.20+ + NVMe 原子写支持，否则风险极高） - 调低持久性换吞吐：
innodb_flush_log_at_trx_commit=2（OS 崩溃丢 1 秒事务） +sync_binlog=1000（binlog 组提交） - 对非唯一二级索引高频更新场景，确认
innodb_change_buffering=all已启用（默认），避免强制刷脏页 - 避免小事务高频 UPDATE：合并为批量 UPDATE 或使用
INSERT ... ON DUPLICATE KEY UPDATE减少 Redo/Undo 生成量
这些配置变更必须结合业务容忍度评估——例如金融类系统几乎无法接受 innodb_flush_log_at_trx_commit=2，而日志类系统则可大幅放宽。
监控写入放大不能只看 slow log
slow log 只记录执行慢的语句，完全不反映写入放大。真实观测要靠三层指标交叉验证：
- MySQL 层：
SHOW ENGINE INNODB STATUS\G中关注 “Log sequence number” 与 “Log flushed up to” 差值（Redo 未刷盘量），以及 “Ibuf size”（Change Buffer 占用） - OS 层：
iostat -x 1看avgrq-sz（平均请求大小）是否长期远高于 16KB（说明存在大量合并写或 RMW） - 硬件层：SSD 厂商工具（如
smartctl -a /dev/nvme0n1）查Media and Data Integrity Errors和Percent Used，间接判断擦除压力
最容易被忽略的是 Change Buffer 的“延迟爆发”：它把随机写转为顺序写，短期降低 I/O，但后台线程合并时会突然拉高磁盘写入，表现为凌晨时段 iowait 飙升——这常被误判为定时任务问题，实则是写入放大在时间维度上的再分配。
