MySQL 8.0+ 中 SET GLOBAL 不可靠，因仅影响新连接且重启丢失；innodb_flush_log_at_trx_commit 为只读变量，不支持 SET PERSIST，必须写入 my.cnf 的 [mysqld] 段并重启生效。
必须写进配置文件并重启 MySQL 才算真正生效，动态 SET 只影响新连接，且 MySQL 8.0+ 不支持 SET PERSIST。
为什么 SET GLOBAL 不可靠
执行 SET GLOBAL innodb_flush_log_at_trx_commit = 2 确实会立刻改变全局值，但：
- 已存在的连接仍按旧值行为运行（比如老连接还在用 1，你却以为全切到 2 了）
- MySQL 重启后该设置丢失，生产环境等于白改
- MySQL 8.0.23+ 直接禁用
SET PERSIST写入持久化配置，报错：“Variable 'innodb_flush_log_at_trx_commit' is a read-only variable”
正确修改位置和格式
编辑 MySQL 配置文件（如 /etc/my.cnf 或 /etc/mysql/conf.d/innodb.cnf），在 [mysqld] 段落下写：
[mysqld] innodb_flush_log_at_trx_commit = 2
注意：
- 值必须是整数，不能加引号：
innodb_flush_log_at_trx_commit = "2"会解析失败 - 不要写在
[client]或[mysql]段——这些段不生效 - 如果多个配置文件都定义了该参数，以最后加载的文件中最后一次出现的值为准
改完必须验证是否落地
重启 MySQL 后，登录执行：
SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
但光看变量值还不够，真实行为得盯底层统计：
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs';，观察每秒调用次数：设为 1 时接近事务提交频次；设为 2 时应稳定在 ~1 次/秒；设为 0 时也接近 ~1 次/秒（但含义不同） - 别只看应用层 TPS 或 p99 延迟——缓存、连接池、网络抖动都会掩盖 I/O 实际变化
别漏掉 sync_binlog 这个搭档
单独调 innodb_flush_log_at_trx_commit 是半截优化。只要开了 binlog（主从、GTID 必开），sync_binlog 就在抢同一块磁盘：
- 默认
sync_binlog = 1，每次 COMMIT 要刷 redo + binlog 两次盘，性能直接腰斩 - 配
innodb_flush_log_at_trx_commit = 2时，建议同步设sync_binlog = 1000或sync_binlog = 0 -
sync_binlog = 0风险明确：binlog 可能比 redo log 少几条，GTID 跳变、主从不一致
真正敢压低这两个值的系统，背后通常有 UPS、BBU RAID 卡或 PMEM 支撑——否则“1 秒”不是数字，是责任边界。
