设成1保证断电不丢已提交事务，2接受OS崩溃最多丢1秒数据，0则MySQL崩溃也可能丢失；必须写入my.cnf并重启生效，且需协同sync_binlog、autocommit等参数调优。
设成 1 就代表你要求断电也不丢已提交事务；设成 2 就等于接受 OS 崩溃时最多丢 1 秒数据；设成 0 则连 MySQL 崩溃都可能丢——选哪个，取决于你敢不敢为这 1 秒担责。
为什么动态 SET 后压测没效果？
执行 SET GLOBAL innodb_flush_log_at_trx_commit = 2 确实立刻生效，但它只影响新建立的连接；老连接（尤其是连接池里复用的）仍按旧值行为运行。生产环境压测时发现延迟没降，大概率是这个原因。
- 必须写进配置文件（如
/etc/my.cnf的[mysqld]段），再重启 MySQL 才能全局生效 - MySQL 8.0+ 不支持
SET PERSIST持久化该参数，报错是正常现象 - 配置项值必须是整数，不能加引号：
innodb_flush_log_at_trx_commit = 2✅，innodb_flush_log_at_trx_commit = "2"❌ - 改完务必验证：
SHOW GLOBAL VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
设成 2 还卡在 I/O？别漏掉 sync_binlog
单独调 innodb_flush_log_at_trx_commit 是半截优化。只要开了 binlog（主从、GTID 必开），sync_binlog 就在抢磁盘：默认 sync_binlog = 1，每次 COMMIT 都要刷 redo log + binlog 两次盘，性能直接打对折。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 搭配
innodb_flush_log_at_trx_commit = 2，建议设sync_binlog = 1000或sync_binlog = 0 -
sync_binlog = 0表示依赖 OS 刷盘，风险是 binlog 可能比 redo log 少几条，导致 GTID 跳变 - 若必须强一致（如金融核心），就别动这两个参数，老老实实用
innodb_flush_log_at_trx_commit = 1+sync_binlog = 1
设成 0 却没变快？autocommit 没关
innodb_flush_log_at_trx_commit = 0 对单条自动提交的 INSERT 几乎无效——因为每条语句都是独立事务，仍走默认日志路径。它只在显式事务里起作用。
- 必须先执行
SET autocommit = 0，再批量 INSERT，最后COMMIT - 配合
INSERT INTO t VALUES (),(),()批量语法，才能把刷盘压力压到每秒一次 - 否则即使参数是 0，每条 INSERT 仍触发 redo log buffer 写入逻辑（只是不 fsync）
怎么确认它真生效了？盯紧 Innodb_os_log_fsyncs
别光看 TPS 或 p99 延迟，这些指标会被缓存、网络、应用层掩盖。真实行为看 MySQL 自身统计：
- 执行
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs'; - 值为 1：说明每秒仅一次 fsync，
innodb_flush_log_at_trx_commit = 0或= 2已生效 - 值接近每秒事务数：大概率还是
= 1，或连接复用未更新配置
最容易被忽略的是：即使参数改对了，如果业务代码没关 autocommit、没批量提交、又开了 binlog 却没调 sync_binlog，那等于白调。
