MySQL 读写分离完全指南:从一次"下单后查不到订单"看懂主从延迟

2022 年我们的订单系统做了一次读写分离:一台 MySQL 主库扛写,两台从库分摊读。上线那几天 QPS 曲线漂亮得让人想截图发群里——主库压力掉了一大半,从库把读流量均匀分走。我以为这次架构升级稳了。结果第三天,客服转来一个用户投诉:他下单付完款,跳回订单列表,页面却显示"暂无订单"。他以为钱白付了,急得连发了三条工单。我登进后台一查,订单明明在,状态也正常。我让他刷新一下,他刷了,订单就出来了。这种"刷新一下就好"的 bug 最让人头皮发麻——它不稳定复现,日志里没有任何报错,代码逻辑挑不出毛病。我盯着那条链路看了很久才反应过来:下单是写,写进的是主库;跳回列表是读,读的是从库;而从库的数据,是异步地从主库复制过来的。在"写完主库"到"从库同步完成"这中间有一个几十毫秒到几秒的时间窗,用户的读请求恰好落在了这个窗口里——他查的是一台还没收到这条订单的从库。这就是主从延迟。那次之后我才真正搞明白:读写分离不是配一个从库地址那么简单,它从你启用的那一刻起,就在系统里引入了一种全新的、默认存在的不一致。这篇文章把这套东西从头梳理一遍:主从复制到底怎么工作、延迟从哪来、怎么监控它、以及怎么在延迟客观存在的前提下,把"刚写完就读不到"这类问题一个个解决掉。

问题背景

先把那次事故的现象和我的误判讲清楚,因为后面所有的排查和方案,都是冲着这个误判去的。

现象:订单系统做了读写分离(一主两从)。用户下单付款成功后,立刻跳回订单列表,偶发性地查不到自己刚下的那一单;手动刷新一次后,订单又正常出现。报错日志里没有任何异常,代码逻辑也挑不出错。

我当时的错误判断:"读写分离就是把读请求指到从库,主库写、从库读,数据是一份,不会有问题。"

真相:主库和从库的数据不是同一份。从库的数据是通过复制、异步地从主库追过来的。从"主库写入成功"到"从库也拥有这条数据",中间永远存在一个时间差——这就是主从延迟。读写分离一旦启用,这个延迟就成了系统的默认属性,"写完立刻就能在从库读到"这个假设从此不再成立。

要把这类问题处理干净,需要几块认知:

• 主从复制到底是怎么把数据从主库搬到从库的,异步发生在哪一步;
• 主从延迟从哪几个环节产生,为什么大事务和从库单线程回放是重灾区;
• 怎么量化监控延迟,Seconds_Behind_Master 这个指标有什么坑;
• "写后读"不一致有哪几种解法,各自的代价是什么;
• 读写分离在工程上还有哪些容易踩的坑。

一、先搞懂主从复制:数据是怎么从主库到从库的

要理解延迟,得先知道一条数据从主库到从库,中间到底走了哪几步。MySQL 的主从复制,核心是围绕主库的 binlog(二进制日志)展开的。

整个流程大致是这样:主库每执行一个写操作(增删改),就把这次变更记进自己的 binlog;从库上有一个 IO 线程,负责连到主库、把主库的 binlog 源源不断地拉过来,写进从库本地的一个文件,叫 relay log(中继日志);从库上还有一个 SQL 线程(新版本里可以是多个),负责读这个 relay log,把里面记录的变更在从库上重新执行一遍。三步走完,从库才算"追上"了主库的这条数据。

这里最关键的一点是:主库执行完写操作、记完 binlog,就直接给客户端返回"成功"了,它根本不会等从库。从库的 IO 线程拉取、SQL 线程回放,全都是在这之后异步进行的。也就是说,"主库写成功"这个信号,和"从库已经拥有这条数据",是两个在时间上分开的事件——这个时间差,就是延迟的根源。

下面这几条命令,是排查复制问题时最先要敲的——在从库上看复制状态,在主库上看 binlog 配置:

-- 在从库上执行:查看复制的整体状态(MySQL 8.0 起推荐用 REPLICA 措辞)
SHOW REPLICA STATUS\G
-- 老版本 / 兼容写法:
-- SHOW SLAVE STATUS\G

-- 重点关注返回结果里的这几行:
--   Replica_IO_Running:  Yes   <- IO 线程是否在拉 binlog
--   Replica_SQL_Running: Yes   <- SQL 线程是否在回放 relay log
--   Seconds_Behind_Source: 0   <- 从库落后主库多少秒(核心延迟指标)
--   Last_Error:                <- 复制中断时,这里是具体报错

-- 在主库上执行:确认 binlog 已开启,并查看当前写到哪个位置
SHOW VARIABLES LIKE 'log_bin';        -- 值应为 ON
SHOW BINARY LOG STATUS\G              -- 当前 binlog 文件名与位点
SHOW BINARY LOGS;                     -- 列出所有 binlog 文件

二、延迟从哪来:大事务和从库单线程回放是重灾区

知道了复制的三步,就能定位延迟具体卡在哪一步。绝大多数延迟,不卡在 IO 线程(拉 binlog 走网络,通常很快),而是卡在 SQL 线程回放这一步。

原因一:从库回放的并行度跟不上主库的并发写。主库是多个连接并发地写,而早期 MySQL 从库的 SQL 线程只有一个,是单线程串行回放。主库一百个线程一起写,从库一个线程慢慢追,一旦主库写入高峰来了,从库天然就会被甩开。MySQL 5.7 之后支持了并行复制,但并行的粒度受限于事务能不能并发,配置不当照样追不上。

原因二:大事务。这是最隐蔽、也最常见的延迟元凶。如果主库上跑了一条 UPDATE 一次改了上百万行,这个事务在主库可能花了 10 秒;它记进 binlog,从库 SQL 线程要把它完整回放一遍,也得花差不多 10 秒——而在这 10 秒里,从库被这一个大事务彻底堵死,后面排队的所有变更全都得等。一条没拆分的批量删除、一次没加 limit 的全表更新,都能让延迟瞬间从 0 飙到几十秒。

原因三:从库自身的压力或配置。从库如果还要扛大量读查询,或者机器配置比主库差、磁盘 IO 慢,回放速度自然就慢。从库的 binlog、双 1 配置(sync_binlog、innodb_flush_log_at_trx_commit)如果设得过于保守,也会拖慢回放。

下面这段 SQL 用来揪出延迟的两大元凶——正在运行的大事务,和当前的并行回放配置:

-- 在主库上:找出当前正在运行的长事务(大事务的典型特征)
-- 运行超过 5 秒还没结束的事务,极可能就是把从库堵住的那个
SELECT trx_id, trx_started,
       TIMESTAMPDIFF(SECOND, trx_started, NOW()) AS run_seconds,
       trx_rows_modified, trx_query
FROM information_schema.innodb_trx
WHERE TIMESTAMPDIFF(SECOND, trx_started, NOW()) > 5
ORDER BY run_seconds DESC;

-- 在从库上:查看并行复制(MTS,多线程回放)的配置
SHOW VARIABLES LIKE 'replica_parallel_workers';   -- 回放线程数,0 表示单线程
SHOW VARIABLES LIKE 'replica_parallel_type';      -- LOGICAL_CLOCK 才是真并行

-- 开启并行回放(在从库上),回放线程数建议设为 CPU 核数附近
SET GLOBAL replica_parallel_type = 'LOGICAL_CLOCK';
SET GLOBAL replica_parallel_workers = 8;
-- 注意:修改后需要重启复制线程才生效
-- STOP REPLICA SQL_THREAD; START REPLICA SQL_THREAD;

三、监控延迟:Seconds_Behind_Master 不能全信

处理延迟之前,得先能"看见"它。最直接的指标是从库 SHOW REPLICA STATUS 里的 Seconds_Behind_Source(老版本叫 Seconds_Behind_Master),但这个指标有几个必须知道的坑,只盯着它会被骗。

坑一:它在复制中断时会显示 NULL,不是 0。如果 IO 线程或 SQL 线程挂了,这个值是 NULL。监控如果只判断"值大于阈值就告警",就会漏掉"复制彻底断了"这种最严重的情况——那时候延迟其实是无穷大。

坑二:大事务回放时它会"跳变"。从库回放一个 10 秒的大事务时,这个值可能在事务回放期间显示得很小甚至 0,等事务回放完才"咔"地跳上去。它反映的是"已回放事件的时间戳",不是"实际落后的体感延迟"。

坑三:它的精度是秒。对延迟敏感的业务,秒级精度太粗了。

更可靠的做法是主动探测:在主库上有一张专门的心跳表,用一个定时任务每秒往里写一次当前时间戳;从库去读这张表里的时间戳,和自己的当前时间一减,得到的就是真实的、端到端的复制延迟。这个方法不受大事务跳变影响,精度也能做到毫秒级。下面是这套心跳监控的实现:

-- 1. 在主库建一张心跳表(只有一行)
CREATE TABLE IF NOT EXISTS repl_heartbeat (
    id      TINYINT      NOT NULL PRIMARY KEY,
    ts      DATETIME(3)  NOT NULL          -- 毫秒精度的时间戳
);
INSERT INTO repl_heartbeat (id, ts) VALUES (1, NOW(3))
ON DUPLICATE KEY UPDATE ts = NOW(3);

-- 2. 在主库上,用定时任务每秒更新一次心跳(下面是 MySQL 事件调度器写法)
SET GLOBAL event_scheduler = ON;
CREATE EVENT IF NOT EXISTS ev_heartbeat
ON SCHEDULE EVERY 1 SECOND
DO
    UPDATE repl_heartbeat SET ts = NOW(3) WHERE id = 1;

-- 3. 在从库上查询真实延迟(单位:毫秒)
--    从库当前时间 - 从库上读到的那条心跳时间戳 = 端到端复制延迟
SELECT TIMESTAMPDIFF(MICROSECOND, ts, NOW(3)) / 1000 AS delay_ms
FROM repl_heartbeat
WHERE id = 1;
-- 这个值不受大事务跳变干扰,复制断了它会持续增大,比 Seconds_Behind 更可信

四、写后读不一致:四种解法和各自的代价

监控解决的是"知道延迟有多大",但业务上真正要解决的,是开头那个"下单后查不到订单"的问题——也就是"写后读一致性"(read-your-writes)。这里有四种主流解法,没有银弹,每一种都是在拿某样东西做交换。

解法一:强制走主库。对一致性要求高的读,直接读主库,不走从库。最简单、最可靠,代价是这部分读流量回到了主库——读写分离的减压效果被打了折扣。它适合"下单后立刻查订单"这种关键且占比不高的场景。

解法二:写后一段时间内强制读主。折中方案:用户做了写操作后,在接下来一小段时间(比如 1 秒,要大于平均延迟)内,他的读请求都路由到主库;过了这个窗口再恢复读从库。它只把"刚写完的那个用户"摁在主库上,对整体减压影响小很多。

解法三:等从库追上(基于 GTID/位点)。写操作完成后,拿到主库当前的 binlog 位点或 GTID;读之前,让从库执行一个"等待函数",阻塞到它回放追上那个位点为止,再读。一致性强,代价是读请求要多等一个延迟的时间。

解法四:从源头干掉延迟来源。不直接处理"写后读",而是把延迟本身压到足够小——拆大事务、开并行复制、用半同步复制。延迟小到几毫秒,"写后读不一致"的窗口就小到业务基本无感。这是最治本的方向,应该和上面的方案配合做。

下面用代码把最常用的"解法一/解法二"落地——一个带"写后强制读主"窗口的数据源路由:

/**
 * 读写分离的数据源路由:决定一次查询走主库还是从库。
 * 核心逻辑:写操作 -> 主库;读操作 -> 默认从库,
 * 但如果该用户刚写过(在强制读主窗口内),则把读也摁到主库。
 */
public class DataSourceRouter {

    // 记录每个用户最近一次写操作的时间戳
    private final Map<Long, Long> lastWriteAt = new ConcurrentHashMap<>();

    // 强制读主的时间窗口:必须大于主从平均延迟,留足余量
    private static final long FORCE_MASTER_WINDOW_MS = 1000;

    /** 用户发生写操作后调用,记下时间戳 */
    public void markWrite(long userId) {
        lastWriteAt.put(userId, System.currentTimeMillis());
    }

    /** 决定这次读该走哪个库 */
    public DbRole routeForRead(long userId) {
        Long writeTs = lastWriteAt.get(userId);
        if (writeTs != null
                && System.currentTimeMillis() - writeTs < FORCE_MASTER_WINDOW_MS) {
            // 该用户刚写过,还在窗口内 —— 读也走主库,保证读到自己的写入
            return DbRole.MASTER;
        }
        // 窗口外,正常走从库,享受读写分离的减压收益
        return DbRole.REPLICA;
    }

    /** 写操作永远走主库 */
    public DbRole routeForWrite(long userId) {
        markWrite(userId);
        return DbRole.MASTER;
    }

    enum DbRole { MASTER, REPLICA }
}

五、用 GTID 让从库"等一等":强一致的写后读

第四节的"解法三"提了一句:写完之后,让读请求等从库追上再读。这一节把它落地。比起"窗口期强制读主"那种基于时间的粗略估计,这个方案是精确的——它不靠猜延迟有多大,而是让从库明确地"回放到某个点"为止。

它依赖 MySQL 的 GTID(全局事务标识)。开启 GTID 后,每个事务都有一个全局唯一的编号。思路是三步:写操作在主库完成后,记下主库"当前已执行到的 GTID";把这个 GTID 随请求带给后续的读;读之前,让从库执行一个等待函数,阻塞到它回放追上那个 GTID(或超时)为止,然后再读。这样读到的数据,一定包含了刚才那笔写入。

代价也很明确:读请求要多花一次"等待"的时间,这个时间约等于当前的主从延迟。所以它适合对一致性要求高、但能容忍读延迟略增的场景。下面是这套机制的 SQL 实现:

-- 前提:主库和从库都已开启 GTID
SHOW VARIABLES LIKE 'gtid_mode';      -- 值应为 ON
SHOW VARIABLES LIKE 'enforce_gtid_consistency';  -- 应为 ON

-- 步骤 1:写操作在主库提交后,立刻取出主库"已执行到的 GTID 集合"
SELECT @@GLOBAL.gtid_executed;
-- 返回形如:3e11fa47-71ca-11e1-9e33-c80aa9429562:1-1000
-- 把这个字符串随请求/会话传给接下来的读操作

-- 步骤 2:读操作之前,在从库上等待回放追上这个 GTID
-- 第二个参数是超时秒数;返回 0 = 已追上,1 = 等待超时
SELECT WAIT_FOR_EXECUTED_GTID_SET(
    '3e11fa47-71ca-11e1-9e33-c80aa9429562:1-1000', 1);

-- 步骤 3:确认追上后再查,这次一定能读到刚才那笔写入
SELECT * FROM orders WHERE user_id = 123 ORDER BY id DESC;
-- 若步骤 2 超时返回 1,说明从库迟迟追不上,应降级去读主库

把这套 SQL 包成一个应用层的"写后读"工具,就是下面这个类。它的关键在于:等待超时后必须有兜底——降级去读主库,而不是把超时的从库结果直接返回:

/**
 * 基于 GTID 的写后读:写完拿到 GTID,读之前等从库追上该 GTID。
 * 比"时间窗口强制读主"更精确 —— 不猜延迟,而是等到确切的点。
 */
public class ReadAfterWrite {

    /** 写操作:在主库执行,并返回主库当前已执行的 GTID */
    public String writeAndGetGtid(Runnable writeOnMaster) {
        writeOnMaster.run();   // 在主库上完成写入
        // 取出主库已执行到的 GTID 集合,作为"读必须追上的目标点"
        return queryOnMaster("SELECT @@GLOBAL.gtid_executed");
    }

    /** 读操作:先让从库追上目标 GTID,追不上就降级读主库 */
    public <T> T readAfterWrite(String targetGtid, ReadQuery<T> query) {
        // 在从库上等待回放追上 targetGtid,超时 1 秒
        String sql = "SELECT WAIT_FOR_EXECUTED_GTID_SET(?, 1)";
        int result = queryWaitOnReplica(sql, targetGtid);

        if (result == 0) {
            // 从库已追上目标点,放心读从库
            return query.runOn(DataSourceRouter.DbRole.REPLICA);
        }
        // 超时:从库还没追上,降级读主库,绝不返回过期数据
        return query.runOn(DataSourceRouter.DbRole.MASTER);
    }

    interface ReadQuery<T> { T runOn(DataSourceRouter.DbRole role); }
}

六、工程坑:从库故障、误写、过期数据、监控盲区

把读写分离真正放进生产环境,还有几个绕不开的工程坑。它们大多不是"复制原理"问题,而是"运维纪律"和"容错设计"问题——而恰恰是这些地方,决定了你的读写分离是"稳定省心"还是"半夜被叫起来"。

坑 1:从库挂了,读请求要能自动降级回主库。从库会宕机、会因为复制中断而数据停滞。如果路由层只会无脑往从库发读请求,从库一出问题,大面积读就会失败或读到陈旧数据。必须有一个健康检查:探测从库的复制线程是否在跑、延迟是否达标,不健康就把读临时切回主库。

坑 2:从库没设只读,被误写导致数据分叉。从库必须开 super_read_only。一旦有人(或某个配错的服务)直接往从库写了数据,这条数据只存在于这台从库、不会同步到主库和其他从库,数据就此分叉,而且极难发现。这是读写分离里最危险的事故之一,务必从配置上堵死。

坑 3:延迟读到的不是"查不到",而是"旧值",这种更隐蔽。开头的订单是"查不到",至少现象明显。但如果用户改了收货地址,立刻刷新看到的还是旧地址——数据是有的,只是旧的——这种 bug 不会报错、也不显眼,却可能造成实际损失。凡是"改完要立刻展示给本人看"的场景,都要套用第四、五节的写后读方案。

坑 4:监控只盯 Seconds_Behind,会有盲区。第三节说过,复制中断时这个值是 NULL。监控必须同时盯三样:Replica_IO_Running 和 Replica_SQL_Running 是否都为 Yes、心跳表算出的真实延迟、以及半同步是否退化成了异步。少盯一样,就可能漏掉一类故障。

下面先用 SQL 把"半同步复制"配起来——它能从根上收紧延迟和丢数据的窗口:

-- 半同步复制:主库提交后,至少等一个从库确认"已收到 binlog"
-- 才向客户端返回成功。它把"完全异步"收紧为"至少一个从库不掉队",
-- 大幅缩小主从延迟窗口,也降低主库宕机时丢数据的风险。

-- 在主库:安装并开启半同步插件
INSTALL PLUGIN rpl_semi_sync_source SONAME 'semisync_source.so';
SET GLOBAL rpl_semi_sync_source_enabled = ON;
SET GLOBAL rpl_semi_sync_source_timeout = 1000;  -- 等从库确认的超时(毫秒)

-- 在从库:安装并开启半同步插件
INSTALL PLUGIN rpl_semi_sync_replica SONAME 'semisync_replica.so';
SET GLOBAL rpl_semi_sync_replica_enabled = ON;

-- 关键:超时后半同步会自动"退化"为异步复制,必须监控这个状态
SHOW STATUS LIKE 'Rpl_semi_sync_source_status';   -- ON = 半同步生效中
SHOW STATUS LIKE 'Rpl_semi_sync_source_clients';  -- 处于半同步的从库数

-- 顺手把从库锁成只读,堵死"误写从库导致数据分叉"这个坑
-- 在每台从库上执行:
SET GLOBAL super_read_only = ON;

再用代码把"坑 1"落地——一个从库健康守卫,不健康就把读降级回主库:

/**
 * 从库健康守卫:周期性探测从库状态,
 * 复制断了或延迟过大,就把读流量临时切回主库。
 */
public class ReplicaHealthGuard {

    private static final long MAX_ACCEPTABLE_DELAY_MS = 3000;
    private volatile boolean replicaHealthy = true;

    /** 定时任务每隔几秒调一次,探测从库 */
    public void checkReplica(ReplicaProbe probe) {
        try {
            if (!probe.isReplicationRunning()) {
                // IO 或 SQL 线程任一不在跑 —— 复制已断,从库数据会越来越旧
                replicaHealthy = false;
                return;
            }
            // 用第三节的心跳表算端到端真实延迟,而不是只信 Seconds_Behind
            long delay = probe.heartbeatDelayMs();
            replicaHealthy = delay <= MAX_ACCEPTABLE_DELAY_MS;
        } catch (Exception e) {
            // 探测本身失败,保守起见判定从库不可用
            replicaHealthy = false;
        }
    }

    /** 路由读请求前先问一句:从库现在能用吗 */
    public DataSourceRouter.DbRole routeForRead() {
        return replicaHealthy
                ? DataSourceRouter.DbRole.REPLICA
                : DataSourceRouter.DbRole.MASTER;   // 不健康就降级读主
    }

    interface ReplicaProbe {
        boolean isReplicationRunning();
        long heartbeatDelayMs();
    }
}

命令速查

避坑清单

1. 读写分离一启用就引入了主从延迟,"写完立刻能在从库读到"这个假设从此不成立,要当成系统默认属性来设计。
2. 主库写完记完 binlog 就返回成功,不等从库;从库 IO 线程拉取、SQL 线程回放都是异步的,延迟根源在这。
3. 延迟绝大多数卡在从库 SQL 线程回放,大事务和单线程回放是两大重灾区,务必拆大事务、开并行复制。
4. 别全信 Seconds_Behind_Master:复制断时它显示 NULL 不是 0,大事务回放时它会跳变,精度只到秒。
5. 用主库心跳表 + 从库读时间戳算端到端真实延迟,毫秒精度且不受大事务跳变干扰,比内置指标可信。
6. "写后读"一致性有四种解法:强制读主、写后窗口期读主、GTID 等待、压低延迟本身,按场景选,没有银弹。
7. 关键且占比不高的读(下单后查订单)直接读主最省心;高一致需求用 GTID 等待法,精确而非靠猜延迟。
8. 从库必须开 super_read_only,否则一旦被误写,数据只存在于单台从库、就此分叉,极难发现和修复。
9. 从库会宕机、会复制中断,路由层必须有健康检查,从库不健康时自动把读降级回主库。
10. 延迟读到的常是"旧值"而非"查不到",这种 bug 不报错更隐蔽,凡是"改完要立刻给本人看"的场景都要套写后读方案。

总结

回头看那次"下单查不到订单"的事故,最值得记的不是最后那段路由代码,而是我上线前心里那个想当然的假设——"数据是一份"。读写分离在架构图上画出来,主库一个框、从库两个框,中间几根箭头,看起来就是"同一份数据多放了几个副本"。但真相是:从你启用读写分离的那一刻起,你的系统里就不再是"一份数据",而是"一份主数据,加上几份永远在追赶、永远慢半拍的副本"。承认这个"慢半拍"是常态,而不是故障,整个设计思路才算走对了第一步。

所以处理主从延迟,真正的心法不是"消灭延迟"——异步复制只要还在,延迟就永远存在,你只能把它压小,压不到零。心法是"承认延迟存在,然后在它之上做一致性设计"。这和我们对待网络的态度是一模一样的:我们从不假设网络永不丢包、永不延迟,我们做的是超时、重试、降级。主从延迟也该这样对待——它就是数据库这一层的"网络延迟",你要做的是监控它、给关键读路径加上写后读保障、给从库故障加上自动降级,而不是指望它消失。

这篇文章的几节内容,其实是顺着一条线展开的。先讲主从复制的三步,是为了让你知道延迟具体产生在哪一步;讲延迟的来源,是为了让你能对症下药——是拆大事务,还是开并行回放;讲监控,是为了让你能"看见"延迟、并且不被 Seconds_Behind 这个有坑的指标骗到;讲写后读的四种解法,是把"偶发查不到"这个最直接的业务痛点收敛成几个可落地的工程方案;最后讲工程坑,是把从库故障、误写、过期数据这些"延迟之外"的暗礁也一并标出来。

读写分离是个好东西,它确实能用很低的成本把数据库的读能力翻几倍。但它不是一个"配好从库地址就完事"的开关,它是一次实实在在的架构权衡——你用"接受一定程度的数据不一致"换来了"读性能的大幅提升"。这笔交易划不划算,取决于你有没有把不一致这一面也认真经营起来:哪些读能容忍旧数据、哪些读必须最新,心里有一本清账;监控能在延迟变大、复制中断时第一时间告警;关键路径上的写后读有兜底。把这些都做扎实了,读写分离才是真正的助力,而不是一个埋在系统里、等着某个深夜把你叫醒的雷。下一次再做这类架构升级,你就会在上线前多问自己一句:这套方案里,哪一份数据是会"慢半拍"的,而我的业务,经得起这半拍吗?

—— 别看了 · 2026