作者： 清朝云

共计 754 个字符，预计需要花费 2 分钟才能阅读完成。

介绍

Tg-Request-Bot 是本人开发的一个专门用于配合 webhook 而开发的程序，它能够根据用户发送的内容发送请求时携带不同的参数。

例如，有这么一个 webhook，它的作用就是请求时重启某个 docker 容器，而这个操作无需登录服务器即可进行操作。但是，每次请求需要重启的容器可能是不同的，那么每次请求 url 的时候都需要传递容器名。而每次访问 url 都需要去浏览器，那么这个操作也是繁琐的，所以通过 tg 机器人可以快速完成这个操作。

/>

项目开源地址：Tg-Request-Bot

搭建

1. 创建机器人

需要找到 Botfather，然后创建新的机器人，获取 Token。

/>

2. 创建配置文件

默认的配置文件为 ./data/config.yaml：

services:
  - name: "百度"
    url: "https://www.baidu.com/"
    method: "GET"
  # 会异常
  - name: "百度带参数"
    url: "https://www.baidu.com/"
    method: "GET"
    param: "wd"
    tips: "请输入查询内容"

• name：功能名称，用于tgbot菜单显示
• url：点击菜单请求的地址
• method：请求 url 的方法，可以是 GET 或者 POST。
• param：请求携带的参数名称。可选，不填则点击菜单直接发送请求。
• tips：点击菜单时，发送给用户的提示语。可选，不填默认提示输入 param 的值。

3. 运行

docker run -d --name tg-request-bot -e API_TOKEN=xxx -e ROW_WIDTH=4 -v /home/docker/tg-request-bot/config.yaml:/app/data/config.yaml hausen1012/tg-request-bot

替换为自己的 Token 即可。

共计 4393 个字符，预计需要花费 11 分钟才能阅读完成。

一、简介

常用的 Ping，Traceroute，nslookup 一般用来判断主机的网络连通性，其实有一个更好用的网络联通性判断工具，这个命令就是 MTR。MTR 结合了 Traceroute 和 Ping 的功能，提供了更为丰富的信息，包括实时的网络状态和统计数据。

Traceroute 默认使用 UDP 数据包探测，而 MTR 默认使用 ICMP 报文探测，ICMP 在某些路由节点的优先级要比其他数据包低，所以测试得到的数据可能低于实际情况。另外 Traceroute 原理, 第 N+1 跳的丢包如小于第 N 跳的丢包, 则说明第 N 跳的丢包是路由器的 ICMP 限制或其他策略导致, 不是网络问题。如果某跳后丢包呈持续增长, 则有可能是网络问题。但实际我们大多数情况，只需要关注最后一跳（目的地址）是否有丢包即可。

特点：

• 动态路由显示：MTR在运行时会持续显示路径上的网络状况，而不是只显示一次路径，这使得MTR在检测临时网络问题时非常有用。

• 数据包类型：MTR默认发送UDP数据包，但也可以配置为发送ICMP Echo请求。

• 显示延迟和丢包：MTR显示每一跳的往返时间（RTT），并可以标记出数据包丢失的跳。

• 过滤和日志：MTR允许用户应用过滤器，以查看特定的路由器或网络段的信息，并可以配置为将诊断结果保存到日志文件中。

• 网络探测：MTR可以在不同的网络协议和端口上运行，以适应不同的网络测试需求

二、MTR命令

首先需要安装 mtr 命令：

sudo apt install -y mtr
# yum install -y mtr

mtr 的基本用法是在命令后跟要测试的域名或 IP 地址。例如：

mtr -rn -c 10 www.baidu.com

常用选项:

• -r：报告模式，指定要发送的数据包数量后停止。(使用ubuntu时，命令行中使用可能需要该选项)
• -c：连续模式，指定要发送的数据包数量后重新开始。
• -i：设置数据包之间的间隔时间（以秒为单位）。
• -s：设置要发送的数据包大小（以字节为单位）。
• -u：使用UDP而不是ICMP来探测。
• -P：设置要使用的ICMP类型。
• -n：禁用DNS解析，只显示IP地址。
• -s：设置ICMP数据包大小。
• -u：使用UDP协议进行探测2.

输出详解：

$ mtr -rn -c 10 www.baidu.com
Start: Thu Jul 11 09:01:13 2024
HOST: wy2                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 9.31.61.130               80.0%    10    0.7   0.7   0.7   0.7   0.0
  2.|-- 9.31.123.100              90.0%    10    0.5   0.5   0.5   0.5   0.0
  3.|-- 10.196.18.125             90.0%    10    1.3   1.3   1.3   1.3   0.0
  4.|-- 10.200.16.177              0.0%    10    0.6   0.6   0.6   0.7   0.0
  5.|-- 10.196.2.101               0.0%    10    0.6   0.6   0.5   0.6   0.0
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- 14.29.117.178              0.0%    10    5.4   5.8   4.7   8.7   1.3
 10.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0
 11.|-- ???                       100.0     3    0.0   0.0   0.0   0.0   0.0
 12.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 13.|-- 183.2.172.42               0.0%     2    3.6   3.6   3.6   3.7   0.0

• Host：当前跳点的IP地址或主机名（如果可用）。
• Loss%：该跳点的丢包率。
• Snt：已发送的数据包数量。
• Last：最后一个数据包的往返时间（RTT）。
• Avg：所有数据包的平均RTT。
• Best：最佳（最小）RTT。
• Wrst：最差（最大）RTT。
• StDev：RTT的标准偏差2.

三、双向MTR

正所谓“条条大路通罗马”，这就好比去北京，有很多种选择：坐飞机、坐火车、坐大巴、自驾、拼车等等，而且不同的人到达北京所走路线（路由）也千差万别。网络的世界也是如此，你可以把去北京的路线理解为网络世界的路由。那么当你自驾去北京的路上发现，部分路段被洪水冲断了，过不去了。那会不会影响其他人，走其他路段自驾去北京呢？当然不会。所以需要谁有故障，谁做 mtr，方便定位到底哪段路有问题，然后进行抢修。（这就是我们常说的网络单点故障）

正如前面所描述，网络单点故障必须客户端提供双向 mtr 报障运营商进行排查，但并不是所有网络故障都是单点故障。比如：运营商骨干网络故障影响范围比较大或者能够 100%复现的网络故障，这种就称之为批次故障。虽然能够复现，但是建议可以直接做完双向 mtr 提供给供应商，方便加速升级运营商处理，避免浪费时间去搭建测试环境。

那么为什么需要双向 mtr 呢？这就好比，我去北京的时候走的是 A 路线，回来的时候走的是 B 路线，那么我走 A 路线很顺利，走 B 路线的时候，出现了大雾封路的情况，自然又过不去了。网络的世界也是如此，我 A 到 B 正常，B 到 A 不正常，那么我的整个网络链路也是异常的，网络也是不通的。所以需要双向 MTR，看看到底断在了 A 还是 B。

就以这段时间购买的 UCloud 香港云服务器为例，发现大陆访问很慢，不知道什么原因，所以需要进行排查。

首先，需要本地 mtr 香港云服务器。

$ mtr -rn -c 10 152.xx.xx.xx
Start: 2024-07-11T09:07:09+0800
HOST: hz                          Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.20.3.254               0.0%    10    3.3   3.3   3.0   3.8   0.3
  2.|-- 172.23.4.254               0.0%    10    1.8   1.6   1.2   2.6   0.4
  3.|-- 172.23.3.10                0.0%    10    1.6   1.5   1.1   1.8   0.2
  4.|-- 61.140.232.1               0.0%    10    3.6  11.4   3.3  33.4  10.6
  5.|-- 61.140.82.125              0.0%    10    6.3   7.2   5.5  12.1   2.4
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 202.97.94.138             50.0%    10   17.6  10.9   5.9  17.6   5.2
  8.|-- 202.97.94.114             10.0%    10   20.8   8.5   5.4  20.8   5.0
  9.|-- 203.86.97.18              20.0%    10  114.9 117.1 114.4 122.8   3.4
 10.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 11.|-- 129.250.2.51              10.0%    10  151.9 152.6 151.9 153.5   0.6
 12.|-- 129.250.4.245             70.0%    10  148.9 149.3 148.9 149.5   0.3
 13.|-- 203.131.241.182           80.0%    10  154.3 154.1 153.8 154.3   0.3
 14.|-- 183.90.191.105            40.0%    10  149.5 150.1 149.5 151.6   0.8
 15.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 16.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 17.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 18.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 19.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 20.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 21.|-- ???                       100.0     9    0.0   0.0   0.0   0.0   0.0
 22.|-- ???                       100.0     9    0.0   0.0   0.0   0.0   0.0
 23.|-- ???                       100.0     9    0.0   0.0   0.0   0.0   0.0
 24.|-- ???                       100.0     8    0.0   0.0   0.0   0.0   0.0
 25.|-- ???                       100.0     6    0.0   0.0   0.0   0.0   0.0
 26.|-- 152.xx.xx.xx              16.7%     6   63.8  64.0  63.7  64.6   0.4

可以看见 129.250.2.51 是美国 ip，129.250.4.245 是英国 ip，去程可以说是在地球饶了一圈才到香港。

那么测试一下香港回来是什么样的网络情况应该怎么样呢？这个时候就需要先获取一下当前网络的出口公网 ip 了，通过如下命令获取：

curl ifconfig.me
# curl myip.ipip.net

获取到以后，在香港云服务器执行 mtr：

$ mtr -rn -c 10 61.140.233.40
Start: 2024-07-11T09:16:38+0800
HOST: 10-7-33-121                 Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  2.|-- 10.67.5.17                 0.0%    10    0.3   0.3   0.2   0.7   0.2
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 10.67.5.17                 0.0%    10    0.4   0.5   0.4   1.2   0.2
  5.|-- 10.67.5.8                  0.0%    10    0.6   0.7   0.5   1.3   0.2
  6.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  7.|-- 10.67.0.138               20.0%    10    2.1   3.1   1.7   6.0   1.8
  8.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  9.|-- 172.21.161.118            90.0%    10    3.7   3.7   3.7   3.7   0.0
 10.|-- 172.21.161.62              0.0%    10    1.0   0.9   0.7   1.3   0.2
 11.|-- 172.21.161.205             0.0%    10   18.4   2.9   0.7  18.4   5.5
 12.|-- 61.14.203.197             10.0%    10    2.0   2.8   2.0   6.0   1.5
 13.|-- 61.14.201.122             10.0%    10    1.5   1.9   1.5   2.5   0.4
 14.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 15.|-- 43.252.86.141              0.0%    10    7.8   5.2   1.6   8.1   2.5
 16.|-- 219.158.6.65               0.0%    10    7.1   8.8   7.0  11.8   1.9
 17.|-- 219.158.3.161              0.0%    10   11.0   9.4   6.3  15.4   3.0
 18.|-- 219.158.3.9                0.0%    10    9.4  10.1   9.1  11.4   0.7
 19.|-- 219.158.24.14              0.0%    10   10.7  10.2   6.1  14.1   2.9
 20.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 21.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
 22.|-- 14.147.7.102              10.0%    10   59.5  84.4  59.5 181.2  44.4
 23.|-- 116.23.47.30               0.0%    10   59.9  62.4  59.5  83.9   7.6
 24.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0

发现回程确实没有绕欧美，也确实如官方所说回程加速。

/>

共计 467 个字符，预计需要花费 2 分钟才能阅读完成。

Centos7 已经在 7 月 1 日彻底停止维护了，所以使用 yum 进行安装时会提示 404，只需要更换 yum 源就好使了。

首先备份配置文件，虽然这个文件以后也用不到了，但是养成好习惯。

sudo mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.bak
# 第三方库源
#sudo wget -O /etc/yum.repos.d/epel.repo http://mirrors.aliyun.com/repo/epel-7.repo

下载阿里云配置文件：

wget -O /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo
# curl -o /etc/yum.repos.d/CentOS-Base.repo https://mirrors.aliyun.com/repo/Centos-7.repo

清理缓存：

sudo yum clean all

更新缓存：

sudo yum makecache

共计 15732 个字符，预计需要花费 40 分钟才能阅读完成。

一、Binlog

1. 简介

MySQL 的二进制日志（Binlog）是一种事务日志，用于记录对数据库的更改操作。

Binlog 主要用于 MySQL 复制和恢复:

• 复制: 从库通过拉取主库的binlog实现主从数据一致
• 恢复: 通过重放binlog恢复数据丢失或误操作情况

2. 原理

在 MySQL 中，每个事务都会在提交后生成相应的 Binlog 记录。MySQL 服务器会为每个客户端连接创建一个线程，称为 Binlog Dump 线程，负责将 Binlog 的内容传送给从服务器，用于数据复制。Binlog 可以在服务器的文件系统中持久化存储，保证了数据的持久性。

3. 格式

MySQL支持多种Binlog格式，包括Statement(语句)、Row(行)和Mixed(混合)三种。不同格式在记录更改时的粒度和复制方式上有所不同：

• Row格式：记录每一行数据的变更，提供了更精确的复制。但产生的日志量较大，因为记录了所有行的变化。(MySQL 8.x 以后的默认格式)
• Statement格式：日志文件较小，因为只记录执行的 SQL 语句，简单高效。但不支持某些类型的语句，比如 UUID()、NOW() 等函数，且可能存在非确定性问题，如触发器的执行结果与主服务器不一致。
• Mixed格式：结合了Statement和Row格式的优点，MySQL根据具体的情况来选择合适的记录方式。

4. 配置

binlog 的相关配置如下，可以在 my.cnf 配置文件的 [mysqld] 进行配置。

[mysqld]
# 启用日志
log_bin = mysql-bin
# 设置 server_id（在主从复制中必须唯一）
server_id = 1
# 日志格式
binlog_format1 = ROW
# 日志文件最大500M
max_binlog_size = 500M
# 保留7天的日志
#expire_logs_days = 7
# binlog缓存大小
binlog_cache_size = 4m
# 最大binlog缓存大小
max_binlog_cache_size = 512m

# 启用 GTID（全局事务标识符）
gtid_mode = ON
enforce_gtid_consistency = ON

# 设置 binlog 忽略和包括的数据库
binlog_ignore_db = mysql
binlog_do_db = mydatabase

二、数据解析

1. mysqlbinlog

mysqlbinlog 是 MySQL 自带的一个实用工具，用于解析二进制日志文件（binlog）。

1. 基本使用：

# binlog-file 为二进制日志文件
mysqlbinlog binlog-file

2. 查看详细日志内容：

mysqlbinlog -v binlog-file

3. 过滤日志

# 按时间过滤
mysqlbinlog --start-datetime="YYYY-MM-DD HH:MM:SS" --stop-datetime="YYYY-MM-DD HH:MM:SS" binlog-file
# 按位置过滤
mysqlbinlog --start-position=POS --stop-position=POS binlog-file
# 特定数据库
mysqlbinlog --database=mydb binlog-file

常见参数如下：

• -d, –database=name: 仅显示指定数据库的转储内容。
• -o, –offset=#: 跳过前N行的日志条目。
• -r, –result-file=name: 将输入的文本格式的文件转储到指定的文件。
• -s, –short-form: 使用简单格式。
• –set-names=name: 在转储文件的开头增加 ‘SET NAMES character_set’ 语句。
• –start-datetime=name: 转储日志的起始时间。
• –stop-datetime=name: 转储日志的截止时间。
• -j, –start-position=#: 转储日志的起始位置。
• –stop-position=#: 转储日志的截止位置

此外，还有一些其他重要参数：

• –no-defaults: 避免读取默认选项文件，解决配置错误问题。
• -v, –verbose: 显示详细信息，重建行格式并显示为带注释的 SQL 语句。
• -vv: 与 -v 类似，但添加字段数据类型注释。
• –base64-output=DECODE-ROWS: 解码基于行的日志事件，显示为 SQL 语句。
• –skip-gtids: 跳过 GTID 信息的解析。
• –include-gtids: 仅显示指定 GTID 集合中的事务。
• –exclude-gtids: 排除显示指定 GTID 集合中的事务。

2. 日志内容

日志解析出来的基本有如下内容：

1. 基本格式

每个事件以 # 开头，后跟事件的描述和时间戳。例如：# at 123456 表示事件在文件中的位置，# 2023-06-21 12:00:00 server id 1 表示事件发生的时间和服务器 ID。

2. SQL语句

如果二进制日志格式是基于语句的，即 Statement格式， mysqlbinlog 将显示实际执行的 SQL 语句。例如：INSERT INTO my_table VALUES (...);。

3. 行事件

如果二进制日志格式是基于行的，mysqlbinlog 将显示行级别的更改，而不是 SQL 语句。使用 --base64-output=DECODE-ROWS 参数可以解码这些行事件，显示为带注释的 SQL 语句。

4. 注释

输出中的注释提供了事件的额外信息，如线程 ID、执行时间、错误代码等。

5. 事务

事务以 BEGIN 开始，以 COMMIT; 或 ROLLBACK; 结束。

6. GTID（全局事务标识符）

在 GTID 格式的日志中，事务前会有 GTID 信息，如 GTID last_committed=1 sequence_number=2 rbr_only=yes。

三、数据恢复案例

1. 数据准备

以下演示一个数据恢复的案例。

docker run -d \
--name mysql8 \
-p 3306:3306 \
-v /home/docker/mysql8/conf.d:/etc/mysql/conf.d  \
-v /home/docker/mysql8/data:/var/lib/mysql \
-v /home/docker/mysql8/init:/docker-entrypoint-initdb.d \
-e MYSQL_ROOT_PASSWORD=123456 \
--restart always mysql:8.0.26

此时运行了一个 mysql8，配置文件可以不配置，因为默认使用的是 row 格式。

然后进入容器里面，执行如下命令：

-- 创建数据库
CREATE DATABASE IF NOT EXISTS TestDB;

-- 使用数据库
USE TestDB;

-- 创建表
CREATE TABLE IF NOT EXISTS Users (
    UserID INT AUTO_INCREMENT,
    UserName VARCHAR(100) NOT NULL,
    UserEmail VARCHAR(100) NOT NULL,
    PRIMARY KEY (UserID)
);

-- 插入数据
INSERT INTO Users (UserName, UserEmail) VALUES ('Alice', 'alice@example.com');
INSERT INTO Users (UserName, UserEmail) VALUES ('Bob', 'bob@example.com');
INSERT INTO Users (UserName, UserEmail) VALUES ('Charlie', 'charlie@example.com');

-- 更新数据
UPDATE Users SET UserEmail = 'alice_new@example.com' WHERE UserName = 'Alice';

-- 删除数据
DELETE FROM Users WHERE UserName = 'Charlie';

-- 删除表
DROP TABLE IF EXISTS Users;

-- 删除数据库
DROP DATABASE IF EXISTS TestDB;

此时数据库看起来什么都没变，但实际上执行的操作已经被 binlog 文件记录下来。

2. 数据解析

先将日志文件解析出看得懂的文本文件，执行如下命令：

# 刷新日志。主要目的是关闭当前的二进制日志文件并打开一个新的二进制日志文件。
mysql -uroot -p -e "FLUSH LOGS;"
# 使用mysqlbinlog工具来解析Binlog文件，并将其中的SQL语句导出到一个文本文件中
mysqlbinlog -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000003 > binlog.sql

这里因为确定所执行的 sql 就在该文件，否则还需要进行查找。

得到的内容如下：

# The proper term is pseudo_replica_mode, but we use this compatibility alias
# to make the statement usable on server versions 8.0.24 and older.
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
DELIMITER /*!*/;
# at 4
#240713  8:23:27 server id 1  end_log_pos 125 CRC32 0x0d7adbe1  Start: binlog v 4, server v 8.0.26 created 240713  8:23:27 at startup
# Warning: this binlog is either in use or was not closed properly.
ROLLBACK/*!*/;
# at 125
#240713  8:23:27 server id 1  end_log_pos 156 CRC32 0x4209701f  Previous-GTIDs
# [empty]
# at 156
#240713  8:24:03 server id 1  end_log_pos 233 CRC32 0x7a245fce  Anonymous_GTID  last_committed=0    sequence_number=1   rbr_only=no original_committed_timestamp=1720859043323243   immediate_commit_timestamp=1720859043323243 transaction_length=205
# original_commit_timestamp=1720859043323243 (2024-07-13 08:24:03.323243 UTC)
# immediate_commit_timestamp=1720859043323243 (2024-07-13 08:24:03.323243 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859043323243*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 233
#240713  8:24:03 server id 1  end_log_pos 361 CRC32 0xa8b3b88d  Query   thread_id=8 exec_time=0 error_code=0    Xid = 3
SET TIMESTAMP=1720859043/*!*/;
SET @@session.pseudo_thread_id=8/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1168113696/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C latin1 *//*!*/;
SET @@session.character_set_client=8,@@session.collation_connection=8,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
/*!80016 SET @@session.default_table_encryption=0*//*!*/;
CREATE DATABASE IF NOT EXISTS TestDB
/*!*/;
# at 361
#240713  8:24:15 server id 1  end_log_pos 440 CRC32 0x75fc9f9e  Anonymous_GTID  last_committed=1    sequence_number=2   rbr_only=no original_committed_timestamp=1720859058772624   immediate_commit_timestamp=1720859058772624 transaction_length=336
# original_commit_timestamp=1720859058772624 (2024-07-13 08:24:18.772624 UTC)
# immediate_commit_timestamp=1720859058772624 (2024-07-13 08:24:18.772624 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859058772624*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 440
#240713  8:24:15 server id 1  end_log_pos 697 CRC32 0x4881934b  Query   thread_id=8 exec_time=3 error_code=0    Xid = 8
use `TestDB`/*!*/;
SET TIMESTAMP=1720859055/*!*/;
/*!80013 SET @@session.sql_require_primary_key=0*//*!*/;
CREATE TABLE IF NOT EXISTS Users (
    UserID INT AUTO_INCREMENT,
    UserName VARCHAR(100) NOT NULL,
    UserEmail VARCHAR(100) NOT NULL,
    PRIMARY KEY (UserID)
)
/*!*/;
# at 697
#240713  8:24:25 server id 1  end_log_pos 776 CRC32 0xf18611a7  Anonymous_GTID  last_committed=2    sequence_number=3   rbr_only=yes    original_committed_timestamp=1720859065477045   immediate_commit_timestamp=1720859065477045 transaction_length=317
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720859065477045 (2024-07-13 08:24:25.477045 UTC)
# immediate_commit_timestamp=1720859065477045 (2024-07-13 08:24:25.477045 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859065477045*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 776
#240713  8:24:25 server id 1  end_log_pos 853 CRC32 0xa770210d  Query   thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1720859065/*!*/;
BEGIN
/*!*/;
# at 853
#240713  8:24:25 server id 1  end_log_pos 917 CRC32 0x904734e2  Table_map: `TestDB`.`Users` mapped to number 89
# at 917
#240713  8:24:25 server id 1  end_log_pos 983 CRC32 0x5c9f4cc8  Write_rows: table id 89 flags: STMT_END_F
### INSERT INTO `TestDB`.`Users`
### SET
###   @1=1
###   @2='Alice'
###   @3='alice@example.com'
# at 983
#240713  8:24:25 server id 1  end_log_pos 1014 CRC32 0xaddd4e19     Xid = 9
COMMIT/*!*/;
# at 1014
#240713  8:24:30 server id 1  end_log_pos 1093 CRC32 0x8ab97df6     Anonymous_GTID  last_committed=3    sequence_number=4   rbr_only=yes    original_committed_timestamp=1720859070654935   immediate_commit_timestamp=1720859070654935 transaction_length=313
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720859070654935 (2024-07-13 08:24:30.654935 UTC)
# immediate_commit_timestamp=1720859070654935 (2024-07-13 08:24:30.654935 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859070654935*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 1093
#240713  8:24:30 server id 1  end_log_pos 1170 CRC32 0x642bc228     Query   thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1720859070/*!*/;
BEGIN
/*!*/;
# at 1170
#240713  8:24:30 server id 1  end_log_pos 1234 CRC32 0x6c6bc11a     Table_map: `TestDB`.`Users` mapped to number 89
# at 1234
#240713  8:24:30 server id 1  end_log_pos 1296 CRC32 0xfa7736c8     Write_rows: table id 89 flags: STMT_END_F
### INSERT INTO `TestDB`.`Users`
### SET
###   @1=2
###   @2='Bob'
###   @3='bob@example.com'
# at 1296
#240713  8:24:30 server id 1  end_log_pos 1327 CRC32 0x5b4c0b9e     Xid = 10
COMMIT/*!*/;
# at 1327
#240713  8:24:35 server id 1  end_log_pos 1406 CRC32 0x556f8f0a     Anonymous_GTID  last_committed=4    sequence_number=5   rbr_only=yes    original_committed_timestamp=1720859075785273   immediate_commit_timestamp=1720859075785273 transaction_length=321
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720859075785273 (2024-07-13 08:24:35.785273 UTC)
# immediate_commit_timestamp=1720859075785273 (2024-07-13 08:24:35.785273 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859075785273*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 1406
#240713  8:24:35 server id 1  end_log_pos 1483 CRC32 0xb24fa262     Query   thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1720859075/*!*/;
BEGIN
/*!*/;
# at 1483
#240713  8:24:35 server id 1  end_log_pos 1547 CRC32 0x86f90af6     Table_map: `TestDB`.`Users` mapped to number 89
# at 1547
#240713  8:24:35 server id 1  end_log_pos 1617 CRC32 0x57177a26     Write_rows: table id 89 flags: STMT_END_F
### INSERT INTO `TestDB`.`Users`
### SET
###   @1=3
###   @2='Charlie'
###   @3='charlie@example.com'
# at 1617
#240713  8:24:35 server id 1  end_log_pos 1648 CRC32 0xd6c2e8c1     Xid = 11
COMMIT/*!*/;
# at 1648
#240713  8:24:47 server id 1  end_log_pos 1727 CRC32 0xee628304     Anonymous_GTID  last_committed=5    sequence_number=6   rbr_only=yes    original_committed_timestamp=1720859087366034   immediate_commit_timestamp=1720859087366034 transaction_length=362
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720859087366034 (2024-07-13 08:24:47.366034 UTC)
# immediate_commit_timestamp=1720859087366034 (2024-07-13 08:24:47.366034 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859087366034*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 1727
#240713  8:24:47 server id 1  end_log_pos 1813 CRC32 0x18249c80     Query   thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1720859087/*!*/;
BEGIN
/*!*/;
# at 1813
#240713  8:24:47 server id 1  end_log_pos 1877 CRC32 0x704bab12     Table_map: `TestDB`.`Users` mapped to number 89
# at 1877
#240713  8:24:47 server id 1  end_log_pos 1979 CRC32 0x9bb1c0b6     Update_rows: table id 89 flags: STMT_END_F
### UPDATE `TestDB`.`Users`
### WHERE
###   @1=1
###   @2='Alice'
###   @3='alice@example.com'
### SET
###   @1=1
###   @2='Alice'
###   @3='alice_new@example.com'
# at 1979
#240713  8:24:47 server id 1  end_log_pos 2010 CRC32 0x3e72c833     Xid = 12
COMMIT/*!*/;
# at 2010
#240713  8:25:03 server id 1  end_log_pos 2089 CRC32 0xc00f3b0c     Anonymous_GTID  last_committed=6    sequence_number=7   rbr_only=yes    original_committed_timestamp=1720859103321244   immediate_commit_timestamp=1720859103321244 transaction_length=321
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720859103321244 (2024-07-13 08:25:03.321244 UTC)
# immediate_commit_timestamp=1720859103321244 (2024-07-13 08:25:03.321244 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859103321244*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 2089
#240713  8:25:03 server id 1  end_log_pos 2166 CRC32 0xdca5c6e2     Query   thread_id=8 exec_time=0 error_code=0
SET TIMESTAMP=1720859103/*!*/;
BEGIN
/*!*/;
# at 2166
#240713  8:25:03 server id 1  end_log_pos 2230 CRC32 0x28c1cab3     Table_map: `TestDB`.`Users` mapped to number 89
# at 2230
#240713  8:25:03 server id 1  end_log_pos 2300 CRC32 0x204184e7     Delete_rows: table id 89 flags: STMT_END_F
### DELETE FROM `TestDB`.`Users`
### WHERE
###   @1=3
###   @2='Charlie'
###   @3='charlie@example.com'
# at 2300
#240713  8:25:03 server id 1  end_log_pos 2331 CRC32 0x098f962d     Xid = 13
COMMIT/*!*/;
# at 2331
#240713  8:25:12 server id 1  end_log_pos 2408 CRC32 0x8f190e29     Anonymous_GTID  last_committed=7    sequence_number=8   rbr_only=no original_committed_timestamp=1720859112568509   immediate_commit_timestamp=1720859112568509 transaction_length=221
# original_commit_timestamp=1720859112568509 (2024-07-13 08:25:12.568509 UTC)
# immediate_commit_timestamp=1720859112568509 (2024-07-13 08:25:12.568509 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859112568509*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 2408
#240713  8:25:12 server id 1  end_log_pos 2552 CRC32 0xdd982cad     Query   thread_id=8 exec_time=0 error_code=0    Xid = 14
SET TIMESTAMP=1720859112/*!*/;
DROP TABLE IF EXISTS `Users` /* generated by server */
/*!*/;
# at 2552
#240713  8:25:18 server id 1  end_log_pos 2629 CRC32 0x763c59b4     Anonymous_GTID  last_committed=8    sequence_number=9   rbr_only=no original_committed_timestamp=1720859118586212   immediate_commit_timestamp=1720859118586212 transaction_length=197
# original_commit_timestamp=1720859118586212 (2024-07-13 08:25:18.586212 UTC)
# immediate_commit_timestamp=1720859118586212 (2024-07-13 08:25:18.586212 UTC)
/*!80001 SET @@session.original_commit_timestamp=1720859118586212*//*!*/;
/*!80014 SET @@session.original_server_version=80026*//*!*/;
/*!80014 SET @@session.immediate_server_version=80026*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 2629
#240713  8:25:18 server id 1  end_log_pos 2749 CRC32 0xdea6f9b6     Query   thread_id=8 exec_time=0 error_code=0    Xid = 15
SET TIMESTAMP=1720859118/*!*/;
DROP DATABASE IF EXISTS TestDB
/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;

可以看见，这里记录了之前对数据库进行的操作。比如现在想恢复 DELETE 之前的记录，那么应该找到如下命令：

DELETE FROM Users WHERE UserName = 'Charlie';

找到相关记录如下：

BEGIN
/*!*/;
# at 2166
#240713  8:25:03 server id 1  end_log_pos 2230 CRC32 0x28c1cab3     Table_map: `TestDB`.`Users` mapped to number 89
# at 2230
#240713  8:25:03 server id 1  end_log_pos 2300 CRC32 0x204184e7     Delete_rows: table id 89 flags: STMT_END_F
### DELETE FROM `TestDB`.`Users`
### WHERE
###   @1=3
###   @2='Charlie'
###   @3='charlie@example.com'
# at 2300
#240713  8:25:03 server id 1  end_log_pos 2331 CRC32 0x098f962d     Xid = 13
COMMIT/*!*/;

3. 数据恢复

此时可以导出需要的内容：

mysqlbinlog --stop-position=2166 /var/lib/mysql/mysql-bin.000003 > binlog.sql

这里是因为确定这个文件里面的内容都是需要的，否则可能还需要指定 –start-position

这里面的内容就是没删除之前的数据了，直接进行恢复即可。

mysql -u root -p < binlog.sql

此时数据就已经恢复了。

/>

当然，如果数据量更多，更复杂，需要根据实际情况进行操作，这里只是一个简单的演示。

需要补充的一点是，注意到 binlog 解析出来的文件：

/** 更新 */
BEGIN
/*!*/;
# at 1813
#240713  8:24:47 server id 1  end_log_pos 1877 CRC32 0x704bab12     Table_map: `TestDB`.`Users` mapped to number 89
# at 1877
#240713  8:24:47 server id 1  end_log_pos 1979 CRC32 0x9bb1c0b6     Update_rows: table id 89 flags: STMT_END_F
### UPDATE `TestDB`.`Users`
### WHERE
###   @1=1
###   @2='Alice'
###   @3='alice@example.com'
### SET
###   @1=1
###   @2='Alice'
###   @3='alice_new@example.com'
# at 1979
#240713  8:24:47 server id 1  end_log_pos 2010 CRC32 0x3e72c833     Xid = 12
COMMIT/*!*/;

/** 删除 */
BEGIN
/*!*/;
# at 2166
#240713  8:25:03 server id 1  end_log_pos 2230 CRC32 0x28c1cab3     Table_map: `TestDB`.`Users` mapped to number 89
# at 2230
#240713  8:25:03 server id 1  end_log_pos 2300 CRC32 0x204184e7     Delete_rows: table id 89 flags: STMT_END_F
### DELETE FROM `TestDB`.`Users`
### WHERE
###   @1=3
###   @2='Charlie'
###   @3='charlie@example.com'
# at 2300
#240713  8:25:03 server id 1  end_log_pos 2331 CRC32 0x098f962d     Xid = 13
COMMIT/*!*/;

这里不管是更新或者是删除，都将原来的字段，并且是所有的值都给列举了出来。而我们原来的更新和删除语句仅仅是根据条件进行的。

如果此时数据库和表没有删除，仅仅是误执行这两个操作，那么可以根据上面的日志进行如下修复：

# 恢复错误的删除
INSERT INTO Users (UserID, UserName, UserEmail) VALUES (3, 'Charlie', 'charlie@example.com');

# 恢复错误的更新
UPDATE Users SET  UserName = 'Alice', UserEmail = 'alice@example.com' WHERE UserID = 1;

共计 4399 个字符，预计需要花费 11 分钟才能阅读完成。

想必大家也听说过数据库单表建议最大2kw条数据这个说法。如果超过了，性能就会下降得比较厉害。

巧了。

我也听说过。

但我不接受它的建议，硬是单表装了1亿条数据。

这时候，我们组里新来的实习生看到了之后，天真无邪的问我：”单表不是建议最大两千万吗？为什么这个表都放了1个亿还不分库分表“？

我能说我是因为懒吗？我当初设计时哪里想到这表竟然能涨这么快。。。

我不能。

说了等于承认自己是开发组里的毒瘤，虽然我确实是，但我不能承认。

我如坐针毡，如芒刺背，如鲠在喉。

开始了一波骚操作。

“我这么做是有道理的”

“虽然这个表很大，但你有没有发现它查询其实还是很快”

“这个2kw是个建议值，我们要来看下这个2kw是怎么来的”

数据库单表行数最大多大？

我们先看下单表行数理论最大值是多少。

建表的SQL是这么写的，

CREATE TABLE `user` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '名字',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`)
) ENGINE=InnoDB AUTO_INCREMENT=100037 DEFAULT CHARSET=utf8;

其中id就是主键。主键本身唯一，也就是说主键的大小可以限制表的上限。

如果主键声明为int大小，也就是32位，那么能支持2^32-1，也就是21个亿左右。

如果是bigint，那就是2^64-1，但这个数字太大，一般还没到这个限制之前，磁盘先受不了。

搞离谱点。

如果我把主键声明为 tinyint，一个字节，8位，最大2^8-1，也就是255。

CREATE TABLE `user` (
  `id` tinyint(2) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(100) NOT NULL DEFAULT '' COMMENT '名字',
  `age` int(11) NOT NULL DEFAULT '0' COMMENT '年龄',
  PRIMARY KEY (`id`),
  KEY `idx_age` (`age`)
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;

如果我想插入一个id=256的数据，那就会报错。

mysql> INSERT INTO `tmp` (`id`, `name`, `age`) VALUES (256, '', 60);
ERROR 1264 (22003): Out of range value for column 'id' at row 1

也就是说，tinyint主键限制表内最多255条数据。

那除了主键，还有哪些因素会影响行数？

索引的结构

索引内部是用的B+树，这个也是八股文老股了，大家估计也背得很熟了。

为了不让大家有过于强烈的审丑疲劳，今天我尝试从另外一个角度给大家讲讲这玩意。

页的结构

假设我们有这么一张user数据表。

/>

/>

图片

user表

其中id是唯一主键。

这看起来的一行行数据，为了方便，我们后面就叫它们record吧。

这张表看起来就跟个excel表格一样。excel的数据在硬盘上是一个xx.excel的文件。

而上面user表数据，在硬盘上其实也是类似，放在了user.ibd文件下。含义是user表的innodb data文件，专业点，又叫表空间。

虽然在数据表里，它们看起来是挨在一起的。但实际上在user.ibd里他们被分成很多小份的数据页，每份大小16k。

类似于下面这样。

/>

/>

图片

ibd文件内部有大量的页

我们把视角聚焦一下，放到页上面。

整个页16k，不大，但record这么多，一页肯定放不下，所以会分开放到很多页里。并且这16k，也不可能全用来放record对吧。

因为record们被分成好多份，放到好多页里了，为了唯一标识具体是哪一页，那就需要引入页号（其实是一个表空间的地址偏移量）。同时为了把这些数据页给关联起来，于是引入了前后指针，用于指向前后的页。这些都被加到了页头里。

页是需要读写的，16k说小也不小，写一半电源线被拔了也是有可能发生的，所以为了保证数据页的正确性，还引入了校验码。这个被加到了页尾。

那剩下的空间，才是用来放我们的record的。而record如果行数特别多的话，进入到页内时挨个遍历，效率也不太行，所以为这些数据生成了一个页目录，具体实现细节不重要。只需要知道，它可以通过二分查找的方式将查找效率从O(n) 变成O(lgn)。

/>

/>

图片

页结构

从页到索引

如果想查一条record，我们可以把表空间里每一页都捞出来，再把里面的record捞出来挨个判断是不是我们要找的。

行数量小的时候，这么操作也没啥问题。

行数量大了，性能就慢了，于是为了加速搜索，我们可以在每个数据页里选出主键id最小的record，而且只需要它们的主键id和所在页的页号。组成新的record，放入到一个新生成的一个数据页中，这个新数据页跟之前的页结构没啥区别，而且大小还是16k。

但为了跟之前的数据页进行区分。数据页里加入了页层级（page level）的信息，从0开始往上算。于是页与页之间就有了上下层级的概念，就像下面这样。

/>

/>

图片

两层B+树结构

突然页跟页之间看起来就像是一棵倒过来的树了。也就是我们常说的B+树索引。

最下面那一层，page level 为0，也就是所谓的叶子结点，其余都叫非叶子结点。

上面展示的是两层的树，如果数据变多了，我们还可以再通过类似的方法，再往上构建一层。就成了三层的树。

/>

/>

图片

三层B+树结构

那现在我们就可以通过这样一棵B+树加速查询。举个例子。

比方说我们想要查找行数据5。会先从顶层页的record们入手。record里包含了主键id和页号（页地址）。看下图黄色的箭头，向左最小id是1，向右最小id是7。那id=5的数据如果存在，那必定在左边箭头。于是顺着的record的页地址就到了6号数据页里，再判断id=5>4，所以肯定在右边的数据页里，于是加载105号数据页。在数据页里找到id=5的数据行，完成查询。

/>

/>

图片

B+树查询过程

另外需要注意的是，上面的页的页号并不是连续的，它们在磁盘里也不一定是挨在一起的。

这个过程中查询了三个页，如果这三个页都在磁盘中（没有被提前加载到内存中），那么最多需要经历三次磁盘IO查询，它们才能被加载到内存中。

B+树承载的记录数量

从上面的结构里可以看出B+树的最末级叶子结点里放了record数据。而非叶子结点里则放了用来加速查询的索引数据。

也就是说

同样一个16k的页，非叶子节点里每一条数据都指向一个新的页，而新的页有两种可能。

• 如果是末级叶子节点的话，那么里面放的就是一行行record数据。
• 如果是非叶子节点，那么就会循环继续指向新的数据页。

假设

• 非叶子结点内指向其他内存页的指针数量为x
• 叶子节点内能容纳的record数量为y
• B+树的层数为z

/>

/>

图片

总行数的计算方法

那这棵B+树放的行数据总量等于 (x ^ (z-1)) * y。

x怎么算

我们回去看数据页的结构。

/>

/>

图片

页结构

非叶子节点里主要放索引查询相关的数据，放的是主键和指向页号。

主键假设是bigint（8Byte），而页号在源码里叫FIL_PAGE_OFFSET（4Byte），那么非叶子节点里的一条数据是12Byte左右。

整个数据页16k， 页头页尾那部分数据全加起来大概128Byte，加上页目录毛估占1k吧。那剩下的15k除以12Byte，等于1280，也就是可以指向x=1280页。

我们常说的二叉树指的是一个结点可以发散出两个新的结点。m叉树一个节点能指向m个新的结点。这个指向新节点的操作就叫扇出（fanout）。

而上面的B+树，它能指向1280个新的节点，恐怖如斯，可以说扇出非常高了。

y的计算

叶子节点和非叶子节点的数据结构是一样的，所以也假设剩下15kb可以发挥。

叶子节点里放的是真正的行数据。假设一条行数据1kb，所以一页里能放y=15行。

行总数计算

回到 (x ^ (z-1)) * y 这个公式。

已知x=1280，y=15。

假设B+树是两层，那z=2。则是(1280 ^ (2-1)) * 15 ≈ 2w

假设B+树是三层，那z=3。则是(1280 ^ (3-1)) * 15 ≈ 2.5kw

这个2.5kw，就是我们常说的单表建议最大行数2kw的由来。毕竟再加一层，数据就大得有点离谱了。三层数据页对应最多三次磁盘IO，也比较合理。

行数超一亿就慢了吗？

上面假设单行数据用了1kb，所以一个数据页能放个15行数据。

如果我单行数据用不了这么多，比如只用了250byte。那么单个数据页能放60行数据。

那同样是三层B+树，单表支持的行数就是 (1280 ^ (3-1)) * 60 ≈ 1个亿。

你看我一个亿的数据，其实也就三层B+树，在这个B+树里要查到某行数据，最多也是三次磁盘IO。所以并不慢。

这就很好的解释了文章开头，为什么我单表1个亿，但查询性能没啥大毛病。

B树承载的记录数量

既然都聊到这里了，我们就顺着这个话题多聊一些吧。

我们都知道，现在mysql的索引都是B+树，而有一种树，跟B+树很像，叫B树，也叫B-树。

它跟B+树最大的区别在于，B+树只在末级叶子结点处放数据表行数据，而B树则会在叶子和非叶子结点上都放。

于是，B树的结构就类似这样

/>

/>

图片

B树结构

B树将行数据都存在非叶子节点上，假设每个数据页还是16kb，掐头去尾每页剩15kb，并且一条数据表行数据还是占1kb，就算不考虑各种页指针的情况下，也只能放个15条数据。数据页扇出明显变少了。

计算可承载的总行数的公式也变成了一个等比数列。

15 + 15^2 +15^3 + ... + 15^z

其中z还是层数的意思。

为了能放2kw左右的数据，需要z>=6。也就是树需要有6层，查一次要访问6个页。假设这6个页并不连续，为了查询其中一条数据，最坏情况需要进行6次磁盘IO。

而B+树同样情况下放2kw数据左右，查一次最多是3次磁盘IO。

磁盘IO越多则越慢，这两者在性能上差距略大。

为此，B+树比B树更适合成为mysql的索引。

总结

• B+树叶子和非叶子结点的数据页都是16k，且数据结构一致，区别在于叶子节点放的是真实的行数据，而非叶子结点放的是主键和下一个页的地址。
• B+树一般有两到三层，由于其高扇出，三层就能支持2kw以上的数据，且一次查询最多1~3次磁盘IO，性能也还行。
• 存储同样量级的数据，B树比B+树层级更高，因此磁盘IO也更多，所以B+树更适合成为mysql索引。
• 索引结构不会影响单表最大行数，2kw也只是推荐值，超过了这个值可能会导致B+树层级更高，影响查询性能。
• 单表最大值还受主键大小和磁盘大小限制。

本文转载于：为什么大家说mysql数据库单表最大两千万？依据是啥？

共计 1010 个字符，预计需要花费 3 分钟才能阅读完成。

在 docker-compose 中，往往会伴随着多个容器的一起的创建和销毁。例如，微服务需要等待 nacos 成功启动以后再进行启动，否则先启动则会启动失败，因为不能在 nocos 上注册自己。

以下是一个简单的案例：

version: '3.1'
services:
  nginx:
    image: nginx
    container_name: nginx
    restart: always
    ports:
      - 80:80
  mysql:
    image: mysql:8.0.26
    container_name: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 123456

假设 nginx 为一个业务服务，并且需要的数据来自 mysql。此时直接使用 docker-compose up -d 启动，发现 nginx 马上可以访问，因为业务服务比 mysql 启动快，但是此时如果是真正的业务服务，还是不能正常提供服务的。并且，有可能等 mysql 启动完成后，还是连接数据库失败的状态，需要重启业务服务才可以提供服务。

为了避免这种问题的出现，需要让 nginx 在 mysql 成功启动以后才进行启动，可以添加 depends_on 选项，告诉 nginx 依赖 mysql 的启动，等它启动以后自己再启动。当然，加了这个还是不够的，只能保证 nginx 在 mysql 后面启动，但是 nginx 启动太快了，所以还是会先启动完成。所以需要添加启动的条件，即给 mysql 添加健康检查，nginx 等 mysql 启动，并健康检查通过以后再启动，文件如下：

version: '3.1'
services:
  nginx:
    image: nginx
    container_name: nginx
    restart: always
    ports:
      - 80:80
    depends_on:
      mysql:
        condition: service_healthy
  mysql:
    image: mysql:8.0.26
    container_name: mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: 123456
    healthcheck:
      test: ["CMD", "mysql", "-u", "root", "-p123456", "-e", "select 1"]
      interval: 5s
      timeout: 3s
      retries: 10

此时运行启动命令，发现 nginx 需要等待一段时间才可以访问，说明达到了想要的效果。

共计 2883 个字符，预计需要花费 8 分钟才能阅读完成。

之前不关注线路这个玩意，所以即使之前看见 nexttrace 这款神器，好像也没有觉得有什么有特点的地方。直到自己真正关注线路，想直到自己买这款服务器的线路绕不饶，用起来好不好，才意识到 nexttrace 的好用之处。

linux 安装非常简单：

curl nxtrace.org/nt |bash

其他系统安装参考开源地址：NTrace-core

以 UCloud 为例，使用官方提供的 UCloud数据中心测试IP。

测试香港线路：

nexttrace 101.36.113.110
NextTrace v1.3.1 2024-05-31T02:04:05Z f303397
[NextTrace API] preferred API IP - 46.3.104.246 - 61.42ms - Misaka.HKG TMP
IP Geo Data Provider: LeoMoeAPI
traceroute to 101.36.113.110, 30 hops max, 52 bytes payload
1   172.20.3.254    *                         RFC1918
                                              3.02 ms / 3.06 ms / 2.96 ms
2   172.23.4.254    *                         RFC1918
                                              1.73 ms / 1.04 ms / 1.26 ms
3   172.23.3.10     *                         RFC1918
                                              1.40 ms / 1.37 ms / 4.73 ms
4   61.140.232.1    AS4134                    中国 广东 广州 天河区 www.chinatelecom.com.cn  电信
                                              3.60 ms / 4.56 ms / 3.61 ms
5   116.23.47.97    AS4134   [CHINANET-GD]    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              71.03 ms / 20.90 ms / 4.29 ms
6   14.147.8.25     AS4134   [CHINANET-GD]    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              * ms / 54.83 ms / 54.09 ms
7   202.97.94.130   AS4134   [CHINANET-BB]    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              * ms / * ms / 105.86 ms
8   202.97.12.9     AS4134   [CHINANET-BB]    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              5.59 ms / 5.57 ms / 5.44 ms
9   129.250.66.157  AS2914   [NTT-BACKBONE]   日本 东京都 东京  gin.ntt.net
    xe-2-5-3-3.a03.tokyjp05.jp.bb.gin.ntt.net   * ms / 115.74 ms / 166.44 ms
10  129.250.5.93    AS2914   [NTT-BACKBONE]   日本 东京都 东京  gin.ntt.net
    ae-5.r32.tokyjp05.jp.bb.gin.ntt.net       116.26 ms / 116.02 ms / 115.47 ms
11  *
12  *
13  129.250.2.169   AS2914   [NTT-BACKBONE]   马来西亚 吉隆坡联邦直辖区 吉隆坡  gin.ntt.net
    ae-7.r23.kslrml02.my.bb.gin.ntt.net       100.28 ms / 98.28 ms / 95.00 ms
14  129.250.3.48    AS2914   [NTT-BACKBONE]   马来西亚 吉隆坡联邦直辖区 吉隆坡  gin.ntt.net
                                              96.56 ms / 96.23 ms / 97.98 ms
15  *
16  129.250.5.28    AS2914   [NTT-BACKBONE]   中国 香港   gin.ntt.net
    ae-0.r26.tkokhk01.hk.bb.gin.ntt.net       * ms / 178.24 ms / 189.86 ms
17  129.250.4.245   AS2914   [NTT-BACKBONE]   中国 香港   gin.ntt.net
                                              * ms / * ms / 227.55 ms
18  *
19  183.90.191.105  AS136897 [APNIC-AP]       中国 香港   enjoyvc.com
                                              * ms / 178.95 ms / 230.03 ms
20  *
21  *
22  *
23  *
24  *
25  *
26  *
27  *
28  *
29  *
30  *
MapTrace URL: https://assets.nxtrace.org/tracemap/7640d57c-8e21-522f-b1a5-832e521ed5e7.html

可以看见该香港线路是先绕日本，再绕到新加坡。访问上面提供的 url，可以更直观地看见：

/>

而洛杉矶地线路就是直连了：

 nexttrace 107.150.102.24
NextTrace v1.3.1 2024-05-31T02:04:05Z f303397
[NextTrace API] preferred API IP - 46.3.104.246 - 61.34ms - Misaka.HKG TMP
IP Geo Data Provider: LeoMoeAPI
traceroute to 107.150.102.24, 30 hops max, 52 bytes payload
1   172.20.3.254    *                         RFC1918
                                              3.09 ms / 3.91 ms / 3.03 ms
2   172.23.4.254    *                         RFC1918
                                              1.04 ms / 1.14 ms / 1.01 ms
3   172.23.3.10     *                         RFC1918
                                              1.42 ms / 1.19 ms / 1.13 ms
4   61.140.232.1    AS4134                    中国 广东 广州 天河区 www.chinatelecom.com.cn  电信
                                              4.99 ms / 13.72 ms / 3.94 ms
5   58.62.247.245   AS4134                    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              11.16 ms / 5.59 ms / 11.20 ms
6   *
7   *
8   202.97.12.5     AS4134   [CHINANET-BB]    中国 广东 广州  www.chinatelecom.com.cn  电信
                                              6.07 ms / 5.87 ms / 5.76 ms
9   202.97.58.226   AS4134   [CHINANET-BB]    美国 加利福尼亚 洛杉矶  www.chinatelecom.com.cn  电信
                                              179.14 ms / 175.87 ms / 180.37 ms
10  218.30.53.134   AS4134   [CHINANET-US]    美国 加利福尼亚 洛杉矶 CT-POP-Zenlayer www.chinatelecom.com.cn  电信
                                              171.39 ms / 170.09 ms / 170.85 ms
11  23.236.97.69    AS21859                   美国 加利福尼亚 洛杉矶  zenlayer.com
                                              172.26 ms / 167.56 ms / 168.09 ms
12  23.236.115.157  AS21859                   美国 加利福尼亚 洛杉矶  zenlayer.com
                                              167.41 ms / 166.75 ms / 166.66 ms
13  *
14  *
15  *
16  *
17  *
18  *
19  *
20  107.150.102.24  AS135377                  美国 加利福尼亚 洛杉矶  ucloud.cn
                                              169.05 ms / 165.04 ms / 165.78 ms
MapTrace URL: https://assets.nxtrace.org/tracemap/fa8df226-9ef5-5f64-b22d-e9a13fbec1cf.html

直观展示：

/>

共计 3646 个字符，预计需要花费 10 分钟才能阅读完成。

rocketmq 是一个开源的消息中间件，以其高性能、高可靠性、高可扩展性和良好的容错性而闻名。它支持多种消息类型，包括但不限于队列模型和发布/订阅模型，能够满足不同场景下的消息传递需求。搭建方式如下：

1. 命令行搭建

首先需要创建一个网络：

docker network create rocketmq

创建 name server 日志和存储目录：

mkdir -p /home/docker/rocketmq/namesrv/logs && \
chown -R 3000:3000 /home/docker/rocketmq/

再运行 name server 容器：

docker run -d --name rmqnamesrv \
-p 9876:9876 \
--network rocketmq \
-v /home/docker/rocketmq/namesrv/logs:/home/rocketmq/logs \
apache/rocketmq:5.1.4 sh mqnamesrv autoCreateTopicEnable=true 

创建 broker 配置文件，注意这里 brokerIP1 的地址需要修改为内网 ip 地址：

mkdir -p /home/docker/rocketmq/broker/conf && \
mkdir -p /home/docker/rocketmq/broker/logs && \
mkdir -p /home/docker/rocketmq/broker/store && \
chown -R 3000:3000 /home/docker/rocketmq/ && \
cat >  /home/docker/rocketmq/broker/conf/broker.conf<<EOF
# Broker配置文件

# NameServer地址，多个地址使用分号隔开
#namesrvAddr=rmqnamesrv:9876

# 集群名称
brokerClusterName=DefaultCluster

# Broker名称，集群部署时需保证唯一性
brokerName=broker-a

# Broker ID，0表示master，正整数表示slave
brokerId=0

# Broker对外服务的监听端口
#listenPort=10911

# Broker服务地址，如果是内网部署，填写内网IP
brokerIP1=127.0.0.1

# Broker HA 地址，供slave同步消息的地址
#brokerIP2=127.0.0.1

# 存储路径配置，根据实际情况调整
#storePathRootDir=/home/rocketmq/store
#storePathCommitLog=/home/rocketmq/store/commitlog
#storePathConsumerQueue=/home/rocketmq/store/consumerqueue
#storePathIndex=/home/rocketmq/store/index
EOF

这里执行 chown -R 3000:3000 /home/docker/rocketmq/ 的目的是，让容器有权限操作这几个目录，因为容器内默认使用 rocketmq 用户，并且 id 为 3000。

当启动容器时指定为 root 用户启动时，就算不修改权限也不会启动报错。但是，logs 文件夹却变成了 /root/logs，所以猜测这个文件夹的位置和运行的用户有关，为了不让目录太混乱，还是选择用默认的 rocketmq 用户启动。

创建 broker 容器：

docker run -d \
--name rmqbroker \
--network rocketmq \
-p 10911:10911 \
-p 10909:10909 \
-e "NAMESRV_ADDR=rmqnamesrv:9876" \
-v /home/docker/rocketmq/broker/conf/broker.conf:/home/rocketmq/conf/broker.conf \
-v /home/docker/rocketmq/broker/logs:/home/rocketmq/logs \
-v /home/docker/rocketmq/broker/store:/home/rocketmq/store \
apache/rocketmq:5.1.4 sh mqbroker autoCreateTopicEnable=true -c /home/rocketmq/conf/broker.conf

如果有如下报错，那么可能是权限问题，把目录映射可以删了试试。
java.lang.NullPointerException
at org.apache.rocketmq.broker.schedule.ScheduleMessageService.configFilePath(ScheduleMessageService.java:271)
at org.apache.rocketmq.common.ConfigManager.persist(ConfigManager.java:82)
at org.apache.rocketmq.broker.BrokerController.shutdownBasicService(BrokerController.java:1409)
at org.apache.rocketmq.broker.BrokerController.shutdown(BrokerController.java:1484)
at org.apache.rocketmq.broker.BrokerStartup.createBrokerController(BrokerStartup.java:242)
at org.apache.rocketmq.broker.BrokerStartup.main(BrokerStartup.java:50)

创建可视化面板容器：

docker run -d \
--name rmqdashboard \
--network rocketmq \
-p 8080:8080 \
-e "JAVA_OPTS=-Xmx256M -Xms256M -Xmn128M -Drocketmq.namesrv.addr=rmqnamesrv:9876" \
apacherocketmq/rocketmq-dashboard:latest

这里创建一个 topic，然后发送一条消息，发现能查询出来两条一样的消息。

/>

但是通过 key 查询却发现只有一条，暂时不清楚是什么原因，可能是面板的 bug。

/>

2. compose搭建

由于容器有三个，所以使用 compose 管理会更方便。当然了，即使使用 compose 运行，依然需要创建上面的配置文件，并配置好权限。

version: '3'
services:
  rmqnamesrv:
    image: apache/rocketmq:5.2.0
    container_name: rmqnamesrv
    command: sh mqnamesrv autoCreateTopicEnable=true
    ports:
      - "9876:9876"
    volumes:
      - /home/docker/rocketmq/namesrv/logs:/home/rocketmq/logs
    networks:
      - rocketmq

  rmqbroker:
    image: apache/rocketmq:5.2.0
    container_name: rmqbroker
    command: sh mqbroker autoCreateTopicEnable=true -c /home/rocketmq/conf/broker.conf
    ports:
      - "10911:10911"
      - "10909:10909"
    volumes:
      - /home/docker/rocketmq/broker/conf/broker.conf:/home/rocketmq/conf/broker.conf
      - /home/docker/rocketmq/broker/logs:/home/rocketmq/logs
      - /home/docker/rocketmq/broker/store:/home/rocketmq/store
    environment:
      - NAMESRV_ADDR=rmqnamesrv:9876
    networks:
      - rocketmq
    depends_on:
      - rmqnamesrv

  rmqdashboard:
    image: apacherocketmq/rocketmq-dashboard:latest
    container_name: rmqdashboard
    environment:
      - JAVA_OPTS=-Xmx256M -Xms256M -Xmn128M -Drocketmq.namesrv.addr=rmqnamesrv:9876
    ports:
      - "8080:8080"
    networks:
      - rocketmq

networks:
  rocketmq:
    driver: bridge