大家好，我是数据库小学妹👋 我踩过的坑，你别再踩。

有段时间，我们组老有人想把`innodb_flush_log_at_trx_commit`从1改成2，理由是压测能快不少。我没直接拦，自己搭了台测试机，把0、1、2三档全跑了一遍，又把"进程崩溃、断电"这两种故障到底丢不丢数据理了一遍。结论先放这儿：丢不丢，看你设几；真正"说了不丢就真不丢"的只有1，而且它没传说中那么慢。下面讲清楚为什么。

## 一、先分清redo落盘的两道门

MySQL靠redo log保证"提交了就不丢"，这叫WAL（先写日志，再改数据页）。但redo从内存到磁盘，中间隔着两层，commit那一刻不一定全走完。

```text
事务提交 → ① 写入 log buffer（MySQL内存）
        → ② 写入 redo log 文件（OS page cache）
        → ③ fsync 刷到磁盘
```

第②步`write`是把log buffer写入OS page cache（操作系统页缓存）。第③步叫"刷盘"，数据才真正落到磁盘。`innodb_flush_log_at_trx_commit`管的，就是提交这一刻redo要走到第几步。第③步之外的兜底刷盘，另有每秒一次的后台动作，跟这个参数是两回事。

很多人把"写入"和"刷盘"混在一起，后面看故障矩阵就会懵。先记住这道分界线，下面的三档才看得懂。

## 二、三档取值，到底差在哪

| 取值 | 提交时做什么 | 兜底刷盘 | 一句话风险 |
| ---- | ---- | ---- | ---- |
| 0 | 什么都不做 | 每秒刷一次 | MySQL进程崩溃也可能丢最近约1秒 |
| 1 | 写入并fsync刷盘 | 无需兜底 | 不丢 |
| 2 | 只写入，不fsync | 每秒刷一次 | MySQL崩溃不丢，断电丢最近约1秒 |

取值0：提交时redo还留在MySQL内存的log buffer里，靠每秒一次的后台动作往外搬。这个档连进程崩溃都赌，一旦崩溃发生在两次搬运之间，已提交的事务会丢。

取值1：每个事务提交都把redo写入并fsync到磁盘。只要磁盘没坏，提交了就是真落盘了，断电也不丢。这是最稳的一档。

取值2：提交时把redo写入操作系统page cache，但不fsync。MySQL进程崩了，数据已经在文件里，OS会继续落盘，不丢。但要是操作系统崩溃或直接断电，page cache里没来得及落盘的那部分就没了。

注意0和2的差别。同样是"最多丢约1秒"，2只赌断电和操作系统崩溃，0连MySQL自己崩溃都赌。这两档看着像，安全等级不一样。

## 三、实测：三档性能差多少

光说机制不过瘾，我直接在测试机上跑了。环境是单机MySQL 8.0.36，4核8G，SSD，为了只测redo这一个变量，先把binlog关掉了。压测用的sysbench自带写负载，表里先灌100万行，每轮跑60秒，测写入TPS。

```bash
sysbench oltp_write_only \
  --table-size=1000000 --threads=64 --time=60 \
  --mysql-db=test run
```

三档结果：

| 取值 | 单线程TPS | 64线程TPS |
| ---- | ---- | ---- |
| 0 | 约2100 | 约14200 |
| 1 | 约480 | 约13500 |
| 2 | 约2050 | 约14000 |

单线程下差距很扎眼。1档每个提交都fsync一次，一次fsync几毫秒，吞吐直接被压到四百多。0和2不做fsync，跑得飞快。

但把并发拉到64线程，1档只比2档慢一点点。原因叫group commit（组提交）。高并发下，一大批事务几乎同时到达，InnoDB会把它们凑成一拨，共享同一次fsync，而不是一个事务一次。fsync的总次数没有跟着事务数线性涨，单次fsync的成本被摊薄了。

想看fsync到底发生了多少次，可以查这个状态变量：

```sql
SHOW GLOBAL STATUS LIKE 'Innodb_os_log_fsyncs';
```

1档跑60秒的fsync次数，远小于提交的事务数，就是这个道理。所以"1档一定慢到没法用"是个误解，单线程才是它的最差工况。

## 四、故障场景：什么情况真的会丢

性能看完，回到最关心的问题：设成0或2，到底什么时候丢？把故障分两类看，矩阵很清楚。

| 参数 | MySQL进程崩溃 | 操作系统崩溃 / 断电 |
| ---- | ---- | ---- |
| 0 | 最多丢约1秒 | 最多丢约1秒 |
| 1 | 不丢 | 不丢 |
| 2 | 不丢 | 最多丢约1秒 |

MySQL崩溃和断电不是一回事。取值2扛得住前者，扛不住后者。很多团队以为"2就是双保险"，其实它只保了进程这一层。

还有两个高频混淆点，顺手讲清。

第一，doublewrite（双写）跟这个参数没关系。双写buffer防的是"数据页写到一半断电"导致的半页损坏，redo防的是"已提交事务不丢"。有人把双写当成redo的兜底，方向就错了。

第二，开了binlog之后，持久性不是redo一家说了算。一次提交要走两阶段：先写redo的prepare，再写binlog，最后redo的commit。binlog没落盘的话，崩溃恢复时为了数据和日志一致，可能把binlog里缺失的事务回滚掉。所以真正想不丢，得`innodb_flush_log_at_trx_commit=1`和`sync_binlog=1`一起上，圈里叫"双1"。只改redo那一半，口子还在。

## 五、生产环境到底该设几

理完机制和实验，选型就落到业务容忍度上。

核心链路，订单、支付、余额、对账这种，没有第二种答案，双1。一次fsync的代价，远小于一次资损的代价。就算单线程慢，靠group commit和加并发也能把吞吐拉回来。

能接受"断电丢最近约1秒"的，用2。很多日志、IM、非核心读多写少库是这类。MySQL进程崩溃不丢这一点，已经覆盖了绝大多数故障。注意这里说的是约1秒，具体窗口受`innodb_flush_log_at_timeout`影响，默认就是1秒。

取值0我一般不推荐。它和2的性能差距很小，却把安全底线从"断电才丢"降到了"进程崩溃也丢"，这笔买卖不划算。除非你明确知道自己在赌什么。

如果你已经在用1，又嫌慢，先别急着降到0、2。先看是不是没有享受到group commit：比如用了连接池但每个连接串行提交、或者单线程批量导数据。这种场景调参数不如改并发。

```sql
-- 查看当前取值
SHOW VARIABLES LIKE 'innodb_flush_log_at_trx_commit';
SHOW VARIABLES LIKE 'sync_binlog';

-- 测试时临时改，重启后失效
SET GLOBAL innodb_flush_log_at_trx_commit = 2;
```

要持久化，得写进my.cnf的[mysqld]段再重启。测试归测试，别把`SET GLOBAL`当生产配置。

## 避坑清单

改完参数忘了持久化，是最常见的坑。`SET GLOBAL`只对当前实例生效，一重启就回到配置文件里的值。生产要改，先改my.cnf，再reload或计划内重启，别让测试值悄悄上线。

别把doublewrite和redo刷盘混为一谈。有人看`innodb_flush_log_at_trx_commit=1`就以为万事大吉，其实双写关没关、binlog的sync_binlog是不是1，都会影响"提交不丢"这个承诺。真要验收，把三个变量一起查一遍。

动这个参数之前，先回答一个问题：你的业务能不能接受断电丢最近1秒？能回答"能"再谈性能，不能就老老实实双1。我见过有人为了压测数字好看把支付库改成2，差点出事。参数好改，数据丢了你赔不起。

## 我的判断

数据库里很多参数，都是拿可靠性换性能。`innodb_flush_log_at_trx_commit`是其中最直白的一个，取值0、1、2，代表你愿意为速度赌掉多少可靠性。

我的态度是：先算清楚那1秒值多少钱，再决定要不要省。group commit已经把1档的代价压得很低，多数场景根本轮不到你去降档。与其研究怎么把1改成2，不如把连接池并发和批量提交做好。

丢数据这种事，一次就够你记住一辈子。别让一个参数，成为事故的注脚。

你用的几？有没有因为调这个参数翻过车？评论区聊聊，我猜不少人是被"改成2快一倍"这句话带偏过。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋


有段时间，我们组老有人想把innodb_flush_log_at_trx_commit从1改成2，理由是压测能快不少。我没直接拦，自己搭了台测试机，把0、1、2三档全跑了一遍，又把"进程崩溃、断电"这两种故障到底丢不丢数据理了一遍。结论先放这儿：丢不丢，看你设几；真正"说了不丢就真不丢"的只有1，而且它没传说中那么慢。下面讲清楚为什么。

MySQL刷盘参数0/1/2实测：订单库改参数前先看丢数据边界

生成图片：不要沿用上面的图片风格，重新生成 4 张文章封面图供我选择，16:9 
主标题：MySQL持久性最佳实践
副标题：redo刷盘参数三档取舍与故障分析
文章概述：实测innodb_flush_log_at_trx_commit的0、1、2三档性能，讲清进程崩溃与断电下的丢数据边界，以及redo、doublewrite、双1的关系，给出选型建议。

数据库

后端

架构设计

MySQL中innodb_flush_log_at_trx_commit参数详解：取值0、1、2对数据安全性和性能的影响。实测数据显示高并发下1档性能损失极小，group commit机制可弥补fsync开销。强调双1配置（配合sync_binlog=1）才是真正不丢数据的保障，2档在断电时会丢数据，0档连进程崩溃都扛不住。

代码解释

MySQL

腾讯云数据库特惠，新用户首单0.5折起


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

MySQL中innodb_flush_log_at_trx_commit参数详解：取值0、1、2对数据安全性和性能的影响。实测数据显示高并发下1档性能损失极小，group commit机制可弥补fsync开销。强调双1配置（配合sync_binlog=1）才是真正不丢数据的保障，2档在断电时会丢数据，0档连进程崩溃都扛...

MySQL刷盘参数0/1/2实测：订单库改参数前先看丢数据边界-腾讯云开发者社区-腾讯云

MySQL刷盘参数0/1/2实测：订单库改参数前先看丢数据边界

MySQL刷盘参数0/1/2实测：订单库改参数前先看丢数据边界

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐