调整 innodb_flush_log_at_trx_commit 参数值从 1 改为 2 或 0 能减少事务提交时的磁盘刷写频率，适用于对数据安全性要求不高但追求高写入吞吐的场景，主要风险是数据库或操作系统崩溃时可能丢失最近 1 秒的事务数据。
先说结论：该优化通过降低日志落盘频率换取写入性能，适合日志类、缓存类或非核心交易业务，核心金融账务系统严禁调整。
- 先定位：确认当前写入瓶颈是否由磁盘 I/O 等待引起，检查
Innodb_log_waits状态。 - 先做：在测试环境验证参数调整为 2 或 0 后的业务数据一致性容忍度。
- 再验证：观察生产环境修改后的 TPS 变化及错误日志，确保无异常刷写报错。
命令速用版
查看当前配置：
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
临时修改（重启失效）：
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
永久修改需写入 my.cnf 或 my.ini 配置文件：
[mysqld]\ninnodb_flush_log_at_trx_commit = 2
为什么会这样
默认值 1 保证每次事务提交都将日志缓冲刷写到磁盘并执行 fsync，确保数据不丢失但 I/O 开销大。
调整为 2 时，事务提交仅刷写到操作系统缓存，每秒由后台线程执行一次磁盘 fsync；调整为 0 时，日志写入和刷写均由后台线程每秒控制。这两种模式减少了事务提交路径上的同步磁盘操作，从而提升写入吞吐量，但失去了事务提交即刻持久化的保证。
分步处理
1. 评估业务容忍度：确认业务是否允许极端情况下丢失 1 秒数据，核心账务系统保持默认值 1。
2. 备份配置：记录当前 my.cnf 配置，防止修改后无法回滚。
3. 修改配置：在测试环境优先应用，确认应用层无异常报错。
4. 灰度上线：在生产低峰期修改全局变量或重启实例应用配置文件。
5. 监控观察：持续关注磁盘 I/O 等待时间和事务延迟。
怎么验证是否生效
执行 SHOW GLOBAL STATUS LIKE 'Innodb_log_waits'; 观察数值增长速率是否放缓。
使用 iostat -x 1 查看磁盘 %util 和 await 指标，确认写入压力是否降低。
检查错误日志 error.log，确认无刷写失败或磁盘已满报错。
常见坑
1. 操作系统崩溃风险：值为 2 时 MySQL 崩溃不丢数据，但操作系统崩溃或断电可能丢失 1 秒数据。
2. RAID 卡缓存：如果 RAID 卡带电池保护缓存，值为 1 的性能损耗可能比预期小，调整收益有限。
3. 主从复制延迟：写入过快可能导致从库回放跟不上，需同步监控复制延迟。
常见问题
innodb_flush_log_at_trx_commit 设为 0 和 2 有什么区别？
值为 2 时事务提交写 OS 缓存，每秒刷盘，MySQL 崩溃不丢数据；值为 0 时事务提交写缓存，每秒刷盘，MySQL 崩溃可能丢失 1 秒数据。
修改该参数会影响读取性能吗？
不会直接影响读取性能，该参数仅控制事务日志的刷写策略，主要优化写入吞吐。
调整后需要重启 MySQL 吗？
使用 SET GLOBAL 命令无需重启立即生效，但重启后恢复默认，永久生效需改配置文件并重启。
参考来源
MySQL Official Documentation - InnoDB Parameters
https://dev.mysql.com/doc/refman/8.0/en/innodb-parameters.html#sysvar_innodb_flush_log_at_trx_commit