Mysql on FelixHao's Blog

MySQL的Checkpoint机制

Mon, 29 Dec 2025 19:34:00 +0800

日志序列号(LSN)和Checkpoint

redo log 的作用是记录对数据库的操作，防止数据库崩溃时，导致的数据丢失。如果对数据行的修改已经被后台线程持久化到磁盘中的数据页中，那 redo log 中记录的对数据库的操作就是多余的。如果不维护 redo log 中冗余的操作，redo log 的大小会随着时间的推移无限增加。而数据库在重启时，会重放 redo log 中记录的操作，由于 redo log 太大，重放 redo log 中的操作时，需要很长的时间。为了解决这个问题，InnoDB 引入 LSN(Log Sequence Number)，Checkpoint。

在 InnoDB 中，redo log 中的每条日志都带有 LSN(Log Sequence Number)。Checkpoint 本质上是一个 LSN，由 InnoDB 进行维护，后台线程每次把脏页进行刷盘，都会对应更新 Checkpoint LSN。redo log 中的日志被 Checkpoint LSN 分成了两个部分:

LSN < Checkpoint LSN 的日志: 表示它们对数据库的操作已经被后台线程持久化到磁盘中的数据页中，因此这部分日志是冗余的，可以被删除了。
LSN > Checkpoint LSN 的日志: 表示它们对数据库的操作还未被后台线程持久化到磁盘中的数据页中，不可以被删除。

redo log 使用情况

redo log 日志是一个大小固定循环使用的文件。InnoDB 根据如下的几个变量来跟踪 redo log 的使用情况

current_lsn: 全局 LSN，最大未分配的 LSN，只增不减，用于分配给最新的 redo log 日志。它根据每条 redo log 日志的大小来进行递增，例如某条 redo log 日志的大小是 500 字节，那么最新的 current_lsn = current_lsn + 500
checkpoint_lsn: 最新一次 checkpoint 对应的 LSN
checkpoint_age: checkpoint_age = current_lsn - checkpoint_lsn

InnoDB 通过 checkpoint_age 以及 MySQL 参数 innodb_redo_log_capacity 来判断 redo log 的使用情况，redo log 可用空间: innodb_redo_log_capacity - checkpont_age

checkpoint_age 越接近 innodb_redo_log_capacity 参数，表示 redo log 可用空间越少
checkpoint_age 离 innodb_redo_log_capacity 参数越远，表示 redo log 可用空间越多

当 redo log 可用空间不够时，需要强制进行刷盘操作，释放磁盘空间。

脏页刷盘流程

后台线程会根据:

redo log 的空间压力
buffer pool 中脏页的比例
刷盘策略(如 adaptive flushing) 等
…

来决定什么时候刷，刷多少页。刷盘流程如下:

选择一个 LSN 作为 Checkpoint LSN
将 Buffer Pool 所有脏页中 LSN 小于 Checkpoint LSN 的脏页进行刷盘
成功刷盘之后，在 redo log 中记录新的 Checkpoint 值。

脏页如何维护 LSN

InnoDB 会为每一条 redo log 分配一个 LSN，对 Buffer Pool 中的数据页进行修改时，除了会将数据页标记为脏页，还会在脏页中记录 LSN，脏页中会记录两个 LSN:

第一次修改数据页的 LSN
最新一次修改数据页的 LSN

后台线程是如何选择脏页的?

先说几个关键的数据结构，都在 Buffer Pool 中:

LRU 链表: 按最近使用程度排数据页，主要用于淘汰冷门数据页。
flush_list 链表: 专门挂载脏页，按第一次修改数据页的 LSN 的大小进行升序排序
free_list: 空闲页链表

InnoDB 中有专门的线程(page_cleaner/flusher thread) 负责按策略刷脏页。

每个脏页都有一个 oldest_modification: 一个 LSN 值。flush_list 是按照 oldest_modification 升序排序的双向链表。每当发现 redo log 占用的空间太多(checkpoint age 接近容量阈值)时，后台线程就会:

从 flush_list 头部挑选 oldest_modification 最小的那部分脏页
将挑选出来的脏页批量写磁盘
写成功后，将脏页从 flush_list 中清除，并重置 oldest_modification，从而变成干净页。
更新 checkpoint_lsn

Mysql事务执行过程

Mon, 29 Dec 2025 12:52:45 +0800

事务执行流程

START TRANSACTION;

UPDATE accounts
SET balance = balance - 100
WHERE id = 1;

UPDATE accounts
SET balance = balance + 100
WHERE id = 2;

COMMIT;

以转账事务为例，看下 MySQL 各组件是如何协同工作的:

客户端发送 START TRANSACTION 命令给 MySQL Server
MySQL Server 收到后，通知 InnoDB 开启事务，并分配事务 ID，
客户端发送第一条 UPDATE 语句，MySQL Server 将 UPDATE 语句交给 InnoDB 执行
InnoDB 查看 UPDATE 语句所涉及的数据行是否在内存的 Buffer Pool 中，如果不在，则将数据行所在的数据页加载到 Buffer Pool 中。
修改数据之前，先对需要修改的数据行上锁。
写 undo log。将修改前的旧值写到 undo log 中
修改 Buffer Pool 中相关数据页的数据行，并将数据页标记为脏页
写 redo log。把对数据行的修改写入 redo log 中
客户端发送第二条 UPDATE 语句，重复 4 - 8 中的步骤
客户端发送 COMMIT; 指令。MySQL Server 收到后，与 InnoDB 开启两阶段提交
MySQL Server 通知 InnoDB 在 redo log 中将事务标记为 PREPARE 状态
InnoDB 成功写入 PREPARE 状态后，给 MySQL Server 回复 ACK
MySQL Server 收到 PREPARE 的 ACK 后，会把本次事务对数据行的修改写入到 bin log 中
MySQL Server 成功写入 bin log 后，会通知 InnoDB 将事务标记为 COMMITED 状态
InnoDB 成功写入 COMMITED 状态后，给 MySQL Server 回复 ACK
MySQL Server 收到 InnoDB 的 ACK 后，通知客户端事务提交成功。
后台线程定期或强制将 Buffer Pool 中部分脏页写入到磁盘的数据页中

具体的流程图如下:

  sequenceDiagram
    autonumber
    participant C as Client
    participant S as MySQL Server
    participant I as InnoDB
    participant BP as InnoDB Buffer Pool
    participant UL as Undo Log
    participant RL as Redo Log
    participant BL as Binlog
    participant CK as Checkpoint & Flusher

    C->>S: START TRANSACTION
    S->>I: trx_begin()

    C->>S: UPDATE accounts ...
    S->>I: exec_update()
    I->>BP: 读/加载数据页
    I->>BP: 对相关数据行加锁
    I->>UL: 写 undo 记录 (旧版本)
    I->>BP: 写数据页，标记为脏页
    I->>RL: 写 redo 日志到 log buffer

    C->>S: COMMIT
    Note over S,I: 事务提交，两阶段提交开始

    S->>I: prepare()
    I->>RL: 写 PREPARE 记录<br/>并刷 redo 到磁盘 (fsync)
    I-->>S: prepare OK

    S->>BL: 写 binlog 事件 + XID
    BL-->>S: 刷 binlog 到磁盘 (fsync)

    S->>I: commit()
    I->>RL: 写 COMMIT 记录到 redo
    I->>BP: 释放锁 / 标记事务已提交
    I-->>S: commit OK

    S-->>C: COMMIT 成功返回

    par 后台线程
        loop
            CK->>BP: 选择部分脏页
            BP->>I: 写回数据文件
            I->>CK: 更新 checkpoint LSN
        end
    end

Bin log 和 Redo log 的两阶段提交

客户端通知 MySQL Server 提交事务
MySQL Server 通知 InnoDB 将本次事务的所有变更提交到 redo log，并将事务的 PREPARE 状态也写入 redo log，PREPARE 状态会带有 XID(事务 ID)。变更全部写入成功后 InnoDB 给 MySQL Server 发送 ACK
MySQL Server 收到 InnoDB 的 ACK 后，将本次事务的所有变更以及 XID(事务 ID) 写入到 bin log 中。写入成功后，MySQL Server 给 InnoDB 发送 ACK
InnoDB 收到 MySQL Server 的 ACK 后，将事务的 COMMITED 状态写入 redo log 中，COMMITED 状态会带有 XID(事务 ID)。成功写入 redo log 后，InnoDB 给 MySQL Server 发送 ACK
MySQL Server 收到 InnoDB 的 ACK 后，给客户端发送事务成功提交的消息。

具体的流程如下:

  sequenceDiagram
    autonumber
    participant App as Client
    participant S as MySQL Server
    participant I as InnoDB
    participant RL as Redo Log
    participant BL as Binlog

    App->>S: COMMIT

    Note over S,RL: 阶段 1：InnoDB prepare
    S->>I: prepare()
    I->>RL: 写本事务所有修改的 redo<br/>并写 PREPARE 记录
    RL-->>I: fsync 持久化成功
    I-->>S: prepare OK (事务进入 prepared 状态)

    Note over S,BL: 阶段 2 上半：写 binlog
    S->>BL: 写 binlog event + XID
    BL-->>S: fsync binlog 成功

    Note over S,RL: 阶段 2 下半：InnoDB commit
    S->>I: commit()
    I->>RL: 写 COMMIT 记录到 redo<br/>(通常不强制 fsync)
    I-->>S: commit OK

    S-->>App: COMMIT 成功返回

在两阶段提交中，以 bin log 中事务的状态为准。例如启动 MySQL 时， bin log 中事务 10101 的状态是 COMMITED，但是在 redo log 中，事务 10101 的状态还是 PREPARE。此时以 bin log 中的事务状态为准，需要在 InnoDB 中进行"补提交"，避免 bin log 中有，但是引擎层没有的情况。对于 bin log 中事务状态是非提交的情况，一律回滚事务。

搭建 Mysql 主从复制

Thu, 25 Dec 2025 16:00:31 +0800

环境

操作系统: debian 12
数据库: mysql 8.4.7

名称	地址
主服务器	192.168.31.111
从服务器	192.168.31.114, 192.168.31.115

搭建步骤

修改主服务器配置

Mysql 配置文件是: /etc/mysql/my.cnf ，在 192.168.31.111 的 my.cnf 文件中加入如下配置

[mysqld]
server_id = 111 # 只能是 1 - (2^32 - 1) 之间的整数
log_bin=mysql-bin # 开启 binlog
# binlog_format=ROW # binglog 格式， ROW 最安全可靠，默认值为 ROW。变量已经被废弃，官方未来打算只支持 ROW 格式
binlog_row_image=FULL # 决定 ROW 模式下，binlog 记录“多少列”。FULL 表示所有列
gtid_mode=ON # 开启全局事务 ID，方便从库自动找到位置进行同步
enforce_gtid_consistency=ON # 强制只允许“GTID 安全”的事务，防止生成无法复制的 GTID
log_replica_updates=ON # 从库执行的复制事件，也写入自己的 binlog。这样从库可以再作为其他从库的主库
sync_binlog=1 # 每次事务提交，都 fsync binlog 到磁盘
innodb_flush_log_at_trx_commit=1 # 控制 InnoDB redo log 刷盘策略，每次提交事务，redo log 都要刷盘。
innodb_flush_method = O_DIRECT # 表示使用  Direct IO, 绕过操作系统的缓存，直接将数据写入磁盘

重启主服务器

systemctl restart mysql

在主库上创建用于数据同步的用户

CREATE USER 'root'@'192.168.31.%' IDENTIFIED BY '111000';
GRANT REPLICATION SLAVE ON *.* TO 'root'@'192.168.31.%';

-- 刷新权限
FLUSH PRIVILEGES;

导出主服务器 192.168.31.111 上的相关数据

mysqldump -u root -p \
  --databases better_rss \
  --single-transaction \
  --set-gtid-purged=OFF \
  --source-data=2 \
  > /root/better_rss_dump.sql

参数解释:

--single-transaction：最关键的一步。它会开启一个事务来读数据，期间主库即使有新数据写入（增删改），备份出的数据也是备份开始那一刻的快照，且不会阻塞主库的读写。
--set-gtid-purged=OFF: 这个参数表示将主库所有数据库的 GTID 范围记录在导出的 SQL 文件头部，因此需要关闭。
--source-data=2：将主库当前的 Binlog 文件名和位置以注释形式记录在 SQL 文件中（作为双重保险）。

将 sql 文件拷贝到从服务器

scp /root/better_rss_dump.sql root@192.168.31.114:/root/
scp /root/better_rss_dump.sql root@192.168.31.115:/root/

修改从服务器配置

Mysql 配置文件是: /etc/mysql/my.cnf ，在 192.168.31.114 和 192.168.31.115 的 my.cnf 文件中加入如下配置

[mysqld]
server_id=114 # 只能是 1 - (2^32 - 1) 之间的整数
gtid_mode=ON # 开启全局事务 ID，方便从库自动找到位置进行同步
enforce_gtid_consistency=ON # 强制只允许“GTID 安全”的事务，防止生成无法复制的 GTID
log_bin=mysql-bin  # 开启 binlog
binlog_format= ROW # binglog 格式， ROW 最安全可靠
log_replica_updates=ON #  # 从库执行的复制事件，也写入自己的 binlog。这样从库可以再作为其他从库的主库
read_only=ON # 限制普通用户只能执行读操作，无法执行写操作。高权限用户不受限制
super_read_only=ON # 限制只能读，不能写。高级权限用户也不能够随便写

注意修改一下 server_id，保证不重复即可:

192.168.31.114: server_id = 114
192.168.31.115: server_id = 115

重启从数据库:

systemctl restart mysql

在从库中导入主库的数据

进入 192.168.31.114 的 Mysql:

mysql -u root -p

执行如下命令:

-- 关闭只读模式
SET GLOBAL super_read_only = 0;
SET GLOBAL read_only = 0;

-- 停止主从复制
STOP REPLICA;
-- 清理之前的错误状态和旧的 GTID 信息
RESET REPLICA ALL;

-- 重置 GTID 和 bin_log
RESET BINARY LOGS AND GTIDS;

-- 退出 mysql
exit;

导入主库数据:

mysql -u root -p < /root/better_rss_dump.sql

进入 Mysql

mysql -u root -p

执行如下的命令:

-- 开启只读模式
SET GLOBAL read_only = 1;
SET GLOBAL super_read_only = 1;

-- 设置同步主机
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST='192.168.31.111',
  SOURCE_PORT=3306,
  SOURCE_USER='root', -- 第三步提前在主库中设置好的用户
  SOURCE_PASSWORD='111000', -- 第三步提前在主库中设置好的密码
  GET_SOURCE_PUBLIC_KEY = 1, -- 当从库使用 caching_sha2_password 认证、且连接没有启用 SSL 时，允许从主库“动态获取 RSA 公钥”，用来安全地传输密码。
  SOURCE_AUTO_POSITION=1; -- 表示自动与主库数据保持一致

-- 开启主从复制
START REPLICA;

-- 检查主从复制的状态
SHOW REPLICA STATUS\G

查看主从复制是否成功的关键参数:

Replica_IO_Running: Yes
Replica_SQL_Running: Yes
Auto_Position: 1

如果看到这三项，说明基于 GTID 的 MySQL 8.4 集群搭建成功

Q & A

ERROR 3546 (HY000) at line 24: @@GLOBAL.GTID_PURGED cannot be changed: the added gtid set must not overlap with @@GLOBAL.GTID_EXECUTED

解决步骤:

进入 mysql

mysql -u root -p

执行

RESET BINARY LOGS AND GTIDS;

Fatal error: The replica I/O thread stops because source and replica have equal MySQL server UUIDs; these UUIDs must be different for replication to work.

解决步骤:

systemctl stop mysql
rm -rf /var/lib/mysql/auto.cnf
systemctl start mysql
mysql -u root -p
show replica status\G

IP 被 Mysql 封锁了怎么办? 操作步骤如下:

进入 Mysql

mysql -u root -p

执行

TRUNCATE TABLE performance_schema.host_cache;

Mysql中的深分页问题

Wed, 08 Oct 2025 22:57:41 +0800

Mysql 中的深分页问题

前言

实现分页需求时，通常都会使用 limit 来实现，但是当 offset 特别大的时候，查询速度会非常的慢。文章将会详细的介绍深分页为什么会导致性能问题以及如何解决这个问题。

环境

CREATE TABLE movies
(
    id                      INT PRIMARY KEY,
    title                   VARCHAR(255),
    vote_average            DECIMAL(4, 3),
    vote_count              INT,
    status                  VARCHAR(50),
    release_date            DATE,
    revenue                 BIGINT,
    runtime                 INT,
    adult                   BOOLEAN,
    backdrop_path           VARCHAR(255),
    budget                  BIGINT,
    homepage                VARCHAR(255),
    imdb_id                 VARCHAR(20),
    original_language       VARCHAR(10),
    original_title          VARCHAR(255),
    overview                TEXT,
    popularity              DECIMAL(8, 3),
    poster_path             VARCHAR(255),
    tagline                 VARCHAR(255),
    production_companies    TEXT,
    production_countries    TEXT,
    spoken_languages        TEXT,
    keywords                TEXT,
    release_year            INT,
    Director                VARCHAR(100),
    AverageRating           DECIMAL(3, 1),
    Poster_Link             VARCHAR(255),
    Certificate             VARCHAR(20),
    IMDB_Rating             DECIMAL(3, 1),
    Meta_score              INT,
    Star1                   VARCHAR(100),
    Star2                   VARCHAR(100),
    Star3                   VARCHAR(100),
    Star4                   VARCHAR(100),
    Writer                  VARCHAR(255),
    Director_of_Photography VARCHAR(255),
    Producers               TEXT,
    Music_Composer          VARCHAR(255),
    genres_list             TEXT,
    Cast_list               TEXT,
    overview_sentiment      DECIMAL(5, 4),
    all_combined_keywords   TEXT
) ENGINE = InnoDB
  DEFAULT CHARSET = utf8mb4;

-- 在 release_date 上创建索引
create index idx_release_date on movies (release_date);

数据量

MySQL root@docker.local.com:test> select count(*) from movies;
+----------+
| count(*) |
+----------+
| 1071607  |
+----------+

1 row in set
Time: 1.120s

慢 SQL

在这种环境下，看下深分页查询需要多长的时间

test> select *
      from movies
      where release_date > '1799-01-01'
      order by release_date, id
      limit 800000, 10
[2025-10-09 13:21:13] 10 rows retrieved starting from 1 in 8 s 456 ms (execution: 8 s 411 ms, fetching: 45 ms)

上述 SQL 花了 8.456s 才执行完毕，已经是非常非常慢的 SQL 了，在生产环境下绝对是灾难级别的问题。看下执行计划:

MySQL root@docker.local.com:test> explain
                               -> select *
                               -> from movies
                               -> where release_date > '1799-01-01'
                               -> order by release_date, id
                               -> limit 800000, 10;
+----+-------------+--------+------------+------+------------------+--------+---------+--------+---------+----------+-----------------------------+
| id | select_type | table  | partitions | type | possible_keys    | key    | key_len | ref    | rows    | filtered | Extra                       |
+----+-------------+--------+------------+------+------------------+--------+---------+--------+---------+----------+-----------------------------+
| 1  | SIMPLE      | movies | <null>     | ALL  | idx_release_date | <null> | <null>  | <null> | 1005233 | 50.0     | Using where; Using filesort |
+----+-------------+--------+------------+------+------------------+--------+---------+--------+---------+----------+-----------------------------+

可以看到，根本没有使用索引，直接进行的全表扫描，同时还用到了文件排序。有读者可能提出: 会不会排序导致了问题呢? 我们看下不使用排序会花费多长的时间:

test> select *
      from movies
      where release_date > '1799-01-01'
      limit 800000, 10
[2025-10-09 13:38:09] 10 rows retrieved starting from 1 in 8 s 365 ms (execution: 8 s 316 ms, fetching: 49 ms)

上述 SQL 依然使用了 8.365s, 并没有比使用了 order by 的 SQL 快多少，依然是灾难级别的 SQL。看下执行计划:

MySQL root@docker.local.com:test> explain
                               -> select *
                               -> from movies
                               -> where release_date > '1799-01-01'
                               -> limit 800000, 10;
+----+-------------+--------+------------+-------+------------------+------------------+---------+--------+--------+----------+----------------------------------+
| id | select_type | table  | partitions | type  | possible_keys    | key              | key_len | ref    | rows   | filtered | Extra                            |
+----+-------------+--------+------------+-------+------------------+------------------+---------+--------+--------+----------+----------------------------------+
| 1  | SIMPLE      | movies | <null>     | range | idx_release_date | idx_release_date | 4       | <null> | 502616 | 100.0    | Using index condition; Using MRR |
+----+-------------+--------+------------+-------+------------------+------------------+---------+--------+--------+----------+----------------------------------+

去除掉排序后，使用了 idx_release_date 索引，但是速度还是非常的慢，这是为什么呢?

SQL 执行过程

在 Mysql 中，SQL 的执行过程如下:

通过 where 进行过滤，找出结果集
SQL 中有 limit N, M，从结果集的第一行开始遍历，直到第 N 行，抛弃前面的 N - 1 行，然后取出后面的 M 行。

读者可能会说: MySQL 为什么不直接从第 N 行开始，而是从第 1 行开始?

主要是 MySQL 没法像数组那样直接根据下标访问数据。MySQL 的数据存放在一个个数据页中，每个数据页存放的行数是不确定的，因此 MySQL 只能够从第一行开始遍历。

深分页慢 SQL 优化

深分页导致慢 SQL 的原因: 遍历一个个的数据页，直到找到所需要的数据。这个过程涉及很多次的 I/O，I/O 操作相对于 CPU 来说是非常缓慢的。

那么该如何进行优化呢?

首先需要明确: MySQL 的分页操作只能够从第一行开始查找。我们没有办法改变 MySQL 的这个行为，我们能够做的是: 减少 MySQL 遍历的数据页，从而减少 I/O 的次数。

一个普通的索引，里面存放的数据是索引列以及主键。而完整的数据行则存放了非常多的字段。因此相同大小的数据页，索引的行数远大于完整的数据行。举个例子:

表有 1GB 数据，每行 1 KB，也就是 100 万条数据
索引 16MB 数据，每行 16 B

假设一个数据页的大小是 64KB，一个数据页可以存放 64 条完整的数据行，而索引可以存放 4000 条. $ 4000 \div 64 = 62.5 $。也就是说遍历索引的速度至少是遍历完整数据行的速度的 62.5 倍。并且遍历索引 I/O 次数更少，真实的速度肯定比 62.5 倍更快。

数据行的大小与索引行的大小差距越大，遍历索引相对于遍历完整数据行的速度就越快。

因此优化深分页的目标就是将分页的操作转移到索引中，让 MySQL 遍历索引而不是遍历完整数据行，怎么办呢? 答案就是: 覆盖索引(covering index) + 延迟关联。

覆盖索引可以避免回表，只在索引树中查询所需要的字段
延迟关联指的是延迟对列的访问，也就是说不直接获取所需要的列。
通过覆盖索引查询到的列与外层查询进行匹配，获取所需要的数据。

慢 SQL

select *
from movies
where release_date > '1799-01-01'
order by release_date, id
limit 800000, 10;

慢 SQL 执行时间

test> select *
      from movies
      where release_date > '1799-01-01'
      order by release_date, id
      limit 800000, 10
[2025-10-09 13:21:13] 10 rows retrieved starting from 1 in 8 s 456 ms (execution: 8 s 411 ms, fetching: 45 ms)

执行了 8.456s

慢 SQL 优化后:

select a.*
from movies as a
         inner join (select id
                     from movies
                     where release_date > '1799-01-01'
                     order by release_date, id
                     limit 800000, 10) as tmp on a.id = tmp.id;

优化后的执行时间:

test> select a.*
      from movies as a
               inner join (select id
                           from movies
                           where release_date > '1799-01-01'
                           order by release_date, id
                           limit 800000, 10) as tmp on a.id = tmp.id
[2025-10-09 15:01:20] 10 rows retrieved starting from 1 in 317 ms (execution: 290 ms, fetching: 27 ms)

只花费了 317ms