2. 首页 > 国产数据库教程 > TiDB教程 > 正文

tidb教程FG064-TiDB Region分裂合并与均衡

教程整理：风哥教程  |  更新时间：2026-04-03  |  教程分类：TiDB教程  |  文档学习：17

本文档风哥主要介绍TiDB Region分裂合并与均衡，包括Region分裂的概念、Region合并的概念、Region均衡的概念、分裂策略、合并策略、均衡策略、分裂实施方案、合并实施方案、均衡实施方案等内容，风哥教程参考TiDB官方文档性能优化相关内容编写，适合DBA人员在学习和测试中使用，如果要应用于生产环境则需要自行确认。更多视频教程www.fgedu.net.cn

Part01-基础概念与理论知识

1.1 Region分裂的概念

Region分裂是指当Region大小超过阈值时，自动分裂成两个或多个更小的Region的过程：学习交流加群风哥微信: itpux-com

Region分裂的特点：

  • 自动触发：当Region大小超过阈值时自动分裂
  • 保持数据有序：分裂后的Region保持数据的有序性
  • 负载均衡：分裂后的数据可以分布到不同的TiKV节点
  • 影响性能：分裂过程会短暂影响性能

1.2 Region合并的概念

Region合并是指当相邻Region大小都较小时，自动合并成一个较大的Region的过程：

# Region合并的概念

## 1. 合并的触发条件
– 相邻Region：两个Region必须是相邻的
– 大小较小：两个Region的大小都小于合并阈值
– 无热点：两个Region都不是热点Region

## 2. 合并的过程
– 选择相邻的小Region
– 发送合并请求
– 执行合并操作
– 更新Region元数据

## 3. 合并的好处
– 减少Region数量：降低管理开销
– 提高查询性能：减少跨Region查询
– 优化存储：减少元数据存储

## 4. 合并的影响
– 短暂影响性能：合并过程会短暂影响性能
– 可能产生热点：合并后可能形成新的热点Region

1.3 Region均衡的概念

Region均衡是指通过PD调度，将Region均匀分布到各个TiKV节点的过程：

# Region均衡的概念

## 1. 均衡的目标
– 均匀分布Region：每个TiKV节点的Region数量大致相同
– 均匀分布Leader：每个TiKV节点的Leader数量大致相同
– 均匀分布热点：热点Region分布到多个TiKV节点

## 2. 均衡的策略风哥提示：
– 复制调度：确保每个Region有足够的副本
– 均衡调度：平衡各TiKV节点的Region数量
– 热点调度：缓解热点Region的压力
– 领导者调度：平衡领导者的分布

## 3. 均衡的实现
– PD监控：监控各TiKV节点的Region分布
– 调度决策：根据监控数据做出调度决策
– 执行调度：执行Region迁移和Leader转移

## 4. 均衡的影响
– 提高系统性能：负载均衡，充分利用资源
– 提高系统稳定性：避免单点故障
– 短暂影响性能：调度过程会短暂影响性能

风哥提示：TiDB的Region分裂、合并与均衡是自动的，但了解其工作原理有助于更好地优化系统性能。学习交流加群风哥QQ113257174

Part02-生产环境规划与建议

2.1 分裂策略

分裂策略要点：

# 分裂策略

## 1. 基于大小的分裂
– 触发条件：Region大小超过region-split-size阈值
– 分裂点：根据Region大小均匀分裂
– 适用场景：适用于数据均匀分布的表

## 2. 基于热点的分裂
– 触发条件：Region成为热点，访问频率高
– 分裂点：根据热点数据分布分裂
– 适用场景：适用于有热点数据的表

## 3. 手动分裂
– 触发方式：通过SQL语句手动分裂
– 分裂点：用户指定
– 适用场景：预知热点数据的表

## 4. 分裂参数设置
– region-split-size：Region分裂大小阈值，默认96MB
– region-max-size：Region最大大小阈值，默认144MB
– region-split-keys：Region分裂的键数量阈值

## 5. 分裂策略选择
– 根据表的大小选择：大表可以设置更大的分裂阈值
– 根据访问模式选择：热点表可以使用基于热点的分裂
– 根据数据分布选择：数据均匀分布的表可以使用基于大小的分裂

2.2 合并策略

合并策略要点：

# 合并策略

## 1. 自动合并
– 触发条件：相邻Region大小都小于合并阈值
– 合并过程：自动选择相邻小Region进行合并
– 适用场景：适用于小表和删除数据后的表

## 2. 手动合并
– 触发方式：通过SQL语句手动合并
– 合并对象：用户指定的相邻Region
– 适用场景：需要手动调整Region分布的场景

## 3. 合并参数设置
– region-merge-size-ratio：合并大小比例，默认0.8
– region-merge-max-exponential-growth：合并指数增长最大值，默认1.0

## 4. 合并策略选择
– 根据Region大小选择：小Region可以合并
– 根据访问模式选择：非热点Region可以合并
– 根据系统负载选择：系统负载低时进行合并

2.3 均衡策略

均衡策略要点：

# 均衡策略

## 1. 复制调度
– 目标：确保每个Region有足够的副本
– 触发条件：Region副本数量不足
– 执行方式：创建新的副本

## 2. 均衡调度
– 目标：平衡各TiKV节点的Region数量
– 触发条件：节点间Region数量差异超过阈值
– 执行方式：迁移Region

## 3. 热点调度
– 目标：缓解热点Region的压力
– 触发条件：Region成为热点
– 执行方式：迁移热点Region或Leader学习交流加群风哥QQ113257174

## 4. 领导者调度
– 目标：平衡各TiKV节点的Leader数量
– 触发条件：节点间Leader数量差异超过阈值
– 执行方式：转移Leader

## 5. 均衡参数设置
– max-schedule-count：最大调度数量，默认16
– hot-region-schedule-limit：热点调度限制，默认4
– replicate-schedule-limit：复制调度限制，默认4
– leader-schedule-limit：领导者调度限制，默认4

## 6. 均衡策略选择
– 根据集群状态选择：根据集群的实际状态选择合适的调度策略
– 根据系统负载选择：系统负载高时减少调度
– 根据业务需求选择：业务高峰期减少调度

生产环境建议：根据业务需求和系统实际情况，选择合适的分裂、合并和均衡策略，避免过度分裂或合并导致性能问题。更多学习教程公众号风哥教程itpux_com

Part03-生产环境项目实施方案

3.1 分裂实施方案

3.1.1 自动分裂配置

# 自动分裂配置

## 1. 调整分裂参数
$ vim /tidb/app/tikv/conf/tikv.toml

[raftstore]
# 调整Region分裂大小阈值
region-split-size = “96MB”
# 调整Region最大大小阈值
region-max-size = “144MB”
# 调整分裂的键数量阈值
region-split-keys = 960000

## 2. 应用配置
$ systemctl restart tikv

## 3. 查看分裂参数
mysql> SHOW CONFIG WHERE type = ‘tikv’ AND name LIKE ‘%region%split%’;

# 输出示例
+——+————————-+————-+———-+
| Type | Name | Value | Source |
+——+————————-+————-+———-+
| tikv | raftstore.region-split-size | 96MB | file |
| tikv | raftstore.region-max-size | 144MB | file |
| tikv | raftstore.region-split-keys | 960000 | file |
+——+————————-+————-+———-+

3.1.2 手动分裂操作

# 手动分裂操作

## 1. 查看Region信息
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_users’;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE | ENTIRE_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| 1 | fgedudb | fgedu_users | t_1000_ | t_1000_7fffffff | 12345 | 192.168.1.20 | 20160 | 12345,12346,12347 | 104857600 | 104857600 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+

## 2. 手动分裂Region
mysql> ADMIN SPLIT REGION 1 BY ‘t_1000_40000000’;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 3. 查看分裂后的Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_users’;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE | ENTIRE_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| 1 | fgedudb | fgedu_users | t_1000_ | t_1000_40000000 | 12345 | 192.168.1.20 | 20160 | 12345,12346,12347 | 52428800 | 52428800 |
| 2 | fgedudb | fgedu_users | t_1000_40000000 | t_1000_7fffffff | 12348 | 192.168.1.21 | 20160 | 12348,12349,12350 | 52428800 | 52428800 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+

## 4. 批量分裂Region
mysql> ADMIN SPLIT REGION 2 BY ‘t_1000_60000000’;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

3.2 合并实施方案

3.2.1 自动合并配置

# 自动合并配置

## 1. 调整合并参数
$ vim /tidb/app/tikv/conf/tikv.toml

[raftstore]
# 调整Region合并大小比例
region-merge-size-ratio = 0.8
# 调整合并指数增长最大值
region-merge-max-exponential-growth = 1.0

## 2. 应用配置
$ systemctl restart tikv

## 3. 查看合并参数
mysql> SHOW CONFIG WHERE type = ‘tikv’ AND name LIKE ‘%region%merge%’;

# 输出示例
+——+————————-+————-+———-+
| Type | Name | Value | Source |
+——+————————-+————-+———-+
| tikv | raftstore.region-merge-size-ratio | 0.8 | file |
| tikv | raftstore.region-merge-max-exponential-growth | 1.0 | file |
+——+————————-+————-+———-+

3.2.2 手动合并操作

# 手动合并操作

## 1. 查看相邻Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_users’ ORDER BY start_key;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE | ENTIRE_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+
| 1 | fgedudb | fgedu_users | t_1000_ | t_1000_40000000 | 12345 | 192.168.1.20 | 20160 | 12345,12346,12347 | 10485760 | 10485760 |
| 2 | fgedudb | fgedu_users | t_1000_40000000 | t_1000_60000000 | 12348 | 192.168.1.21 | 20160 | 12348,12349,12350 | 10485760 | 10485760 |
| 3 | fgedudb | fgedu_users | t_1000_60000000 | t_1000_7fffffff | 12351 | 192.168.1.22 | 20160 | 12351,12352,12353 | 10485760 | 10485760 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+——————-+

## 2. 手动合并Region
mysql> ADMIN MERGE REGION 1, 2;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 3. 查看合并后的Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_users’;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| 1 | fgedudb | fgedu_users | t_1000_ | t_1000_60000000 | 12345 | 192.168.1.20 | 20160 | 12345,12346,12347 | 20971520 |
| 3 | fgedudb | fgedu_users | t_1000_60000000 | t_1000_7fffffff | 12351 | 192.168.1.22 | 20160 | 12351,12352,12353 | 10485760 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+

## 4. 继续合并Region
mysql> ADMIN MERGE REGION 1, 3;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

3.3 均衡实施方案

3.3.1 PD调度配置

# PD调度配置

## 1. 调整PD调度参数
$ vim /tidb/app/pd/conf/pd.toml

[scheduler]
# 调整最大调度数量
max-schedule-count = 16
# 调整热点调度限制
hot-region-schedule-limit = 4
# 调整复制调度限制
replicate-schedule-limit = 4
# 调整领导者调度限制
leader-schedule-limit = 4
# 调整存储均衡阈值
t Store-balance-rate = 10

## 2. 应用配置
$ systemctl restart pd

## 3. 查看调度参数
mysql> SHOW CONFIG WHERE type = ‘pd’ AND name LIKE ‘%schedule%’;

# 输出示例
+——+————————-+————-+———-+
| Type | Name | Value | Source |
+——+————————-+————-+———-+
| pd | scheduler.max-schedule-count | 16 | file |
| pd | scheduler.hot-region-schedule-limit | 4 | file |
| pd | scheduler.replicate-schedule-limit | 4 | file |
| pd | scheduler.leader-schedule-limit | 4 | file |
| pd | scheduler.store-balance-rate | 10 | file |
+——+————————-+————-+———-+

3.3.2 手动触发均衡

# 手动触发均衡

## 1. 查看Region分布
mysql> SELECT peer_store_id, COUNT(*) AS region_count
-> FROM information_schema.tikv_region_status
-> GROUP BY peer_store_id
-> ORDER BY region_count DESC;

# 输出示例
+————-+————–+
| peer_store_id | region_count |
+————-+————–+
| 1 | 1000 |
| 2 | 800 |
| 3 | 700 |
+————-+————–+

## 2. 手动触发均衡
mysql> ADMIN SCHEDULER CONFIGURE balance-region, “{\”enable\”: true}”;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 3. 查看均衡状态
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ LIMIT 10;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| 1 | fgedudb | fgedu_users | t_1000_ | t_1000_7fffffff | 12345 | 192.168.1.20 | 20160 | 12345,12346,12347 | 31457280 |
| 4 | fgedudb | fgedu_orders | t_1001_ | t_1001_7fffffff | 12354 | 192.168.1.21 | 20160 | 12354,12355,12356 | 52428800 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+

## 4. 验证均衡效果
mysql> SELECT peer_store_id, COUNT(*) AS region_count
-> FROM information_schema.tikv_region_status
-> GROUP BY peer_store_id
-> ORDER BY region_count DESC;

# 输出示例
+————-+————–+
| peer_store_id | region_count |
+————-+————–+
| 1 | 833 |
| 2 | 833 |
| 3 | 834 |
+————-+————–+

风哥提示：TiDB的Region均衡是自动的，但通过手动触发可以加速均衡过程，特别是在集群拓扑变化后。from tidb视频:www.itpux.com

Part04-生产案例与实战讲解

4.1 分裂实战

4.1.1 热点Region分裂

# 热点Region分裂

## 1. 问题：热点Region导致性能下降
– 现象：某个TiKV节点CPU使用率高，其他节点正常
– 原因：热点Region集中在某个TiKV节点
– 解决方案：手动分裂热点Region，分散热点

## 2. 查看热点Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ ORDER BY region_size DESC LIMIT 10;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| 5 | fgedudb | fgedu_orders | t_1002_ | t_1002_7fffffff | 12357 | 192.168.1.20 | 20160 | 12357,12358,12359 | 104857600 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+

## 3. 手动分裂热点Region
mysql> ADMIN SPLIT REGION 5 BY ‘t_1002_20000000’, ‘t_1002_40000000’, ‘t_1002_60000000’;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 4. 查看分裂后的Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_orders’;

# 输出示例
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+
| 5 | fgedudb | fgedu_orders | t_1002_ | t_1002_20000000 | 12357 | 192.168.1.20 | 20160 | 12357,12358,12359 | 26214400 |
| 6 | fgedudb | fgedu_orders | t_1002_20000000 | t_1002_40000000 | 12360 | 192.168.1.21 | 20160 | 12360,12361,12362 | 26214400 |
| 7 | fgedudb | fgedu_orders | t_1002_40000000 | t_1002_60000000 | 12363 | 192.168.1.22 | 20160 | 12363,12364,12365 | 26214400 |
| 8 | fgedudb | fgedu_orders | t_1002_60000000 | t_1002_7fffffff | 12366 | 192.168.1.20 | 20160 | 12366,12367,12368 | 26214400 |
+———–+———+————+———–+—————-+—————-+————+——————+——————+——————-+

## 5. 验证优化效果
– 查看TiKV节点CPU使用率：top
– 查看SQL执行时间：SET profiling = 1; SELECT * FROM fgedu_orders WHERE id > 1000; SHOW PROFILES;

4.1.2 大表分裂

# 大表分裂

## 1. 问题：大表导致Region过大
– 现象：某个表的Region大小超过阈值，影响性能
– 原因：表数据量过大，Region自动分裂不及时
– 解决方案：手动分裂大表Region，提高查询性能

## 2. 创建大表并插入数据
mysql> CREATE TABLE fgedu_large_table (
-> id INT PRIMARY KEY,
-> name VARCHAR(100),
-> data VARCHAR(1000)
-> );

# 输出示例
Query OK, 0 rows affected (0.02 sec)

mysql> DELIMITER //
mysql> CREATE PROCEDURE insert_data()
BEGIN
DECLARE i INT DEFAULT 1;
WHILE i <= 100000 DO INSERT INTO fgedu_large_table VALUES (i, CONCAT('name', i), REPEAT('a', 1000)); SET i = i + 1; END WHILE; END // mysql> DELIMITER ;
mysql> CALL insert_data();

# 输出示例
Query OK, 1 row affected (10.00 sec)

## 3. 查看Region信息
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_large_table’;

# 输出示例
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| 9 | fgedudb | fgedu_large_table | t_1003_ | t_1003_7fffffff | 12369 | 192.168.1.21 | 20160 | 12369,12370,12371 | 104857600 |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+

## 4. 手动分裂大表Region
mysql> ADMIN SPLIT REGION 9 BY ‘t_1003_10000000’, ‘t_1003_20000000’, ‘t_1003_30000000’, ‘t_1003_40000000’, ‘t_1003_50000000’, ‘t_1003_60000000’;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 5. 查看分裂后的Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_large_table’;

# 输出示例
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| 9 | fgedudb | fgedu_large_table | t_1003_ | t_1003_10000000 | 12369 | 192.168.1.21 | 20160 | 12369,12370,12371 | 17408000 |
| 10 | fgedudb | fgedu_large_table | t_1003_10000000 | t_1003_20000000 | 12372 | 192.168.1.22 | 20160 | 12372,12373,12374 | 17408000 |
| 11 | fgedudb | fgedu_large_table | t_1003_20000000 | t_1003_30000000 | 12375 | 192.168.1.20 | 20160 | 12375,12376,12377 | 17408000 |
| 12 | fgedudb | fgedu_large_table | t_1003_30000000 | t_1003_40000000 | 12378 | 192.168.1.21 | 20160 | 12378,12379,12380 | 17408000 |
| 13 | fgedudb | fgedu_large_table | t_1003_40000000 | t_1003_50000000 | 12381 | 192.168.1.22 | 20160 | 12381,12382,12383 | 17408000 |
| 14 | fgedudb | fgedu_large_table | t_1003_50000000 | t_1003_60000000 | 12384 | 192.168.1.20 | 20160 | 12384,12385,12386 | 17408000 |
| 15 | fgedudb | fgedu_large_table | t_1003_60000000 | t_1003_7fffffff | 12387 | 192.168.1.21 | 20160 | 12387,12388,12389 | 17408000 |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+

## 6. 验证优化效果
– 查看查询性能：SET profiling = 1; SELECT * FROM fgedu_large_table WHERE id BETWEEN 1 AND 1000; SHOW PROFILES;

4.2 合并实战

4.2.1 小Region合并

# 小Region合并

## 1. 问题：小Region过多，影响管理效率
– 现象：表中有很多小Region，管理开销大
– 原因：删除数据后，Region变小但未自动合并
– 解决方案：手动合并小Region，减少管理开销

## 2. 删除部分数据，使Region变小
mysql> DELETE FROM fgedu_large_table WHERE id > 50000;

# 输出示例
Query OK, 50000 rows affected (5.00 sec)

## 3. 查看Region信息
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_large_table’ ORDER BY start_key;

# 输出示例
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| 9 | fgedudb | fgedu_large_table | t_1003_ | t_1003_10000000 | 12369 | 192.168.1.21 | 20160 | 12369,12370,12371 | 17408000 |
| 10 | fgedudb | fgedu_large_table | t_1003_10000000 | t_1003_20000000 | 12372 | 192.168.1.22 | 20160 | 12372,12373,12374 | 17408000 |
| 11 | fgedudb | fgedu_large_table | t_1003_20000000 | t_1003_30000000 | 12375 | 192.168.1.20 | 20160 | 12375,12376,12377 | 17408000 |
| 12 | fgedudb | fgedu_large_table | t_1003_30000000 | t_1003_40000000 | 12378 | 192.168.1.21 | 20160 | 12378,12379,12380 | 17408000 |
| 13 | fgedudb | fgedu_large_table | t_1003_40000000 | t_1003_50000000 | 12381 | 192.168.1.22 | 20160 | 12381,12382,12383 | 17408000 |
| 14 | fgedudb | fgedu_large_table | t_1003_50000000 | t_1003_60000000 | 12384 | 192.168.1.20 | 20160 | 12384,12385,12386 | 8704000 |
| 15 | fgedudb | fgedu_large_table | t_1003_60000000 | t_1003_7fffffff | 12387 | 192.168.1.21 | 20160 | 12387,12388,12389 | 8704000 |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+

## 4. 手动合并小Region
mysql> ADMIN MERGE REGION 14, 15;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 5. 查看合并后的Region
mysql> SELECT * FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_large_table’ ORDER BY start_key;

# 输出示例
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| REGION_ID | DB_NAME | TABLE_NAME | START_KEY | END_KEY | LEADER_ID | LEADER_IP | LEADER_PORT | PEERS | REGION_SIZE |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+
| 9 | fgedudb | fgedu_large_table | t_1003_ | t_1003_10000000 | 12369 | 192.168.1.21 | 20160 | 12369,12370,12371 | 17408000 |
| 10 | fgedudb | fgedu_large_table | t_1003_10000000 | t_1003_20000000 | 12372 | 192.168.1.22 | 20160 | 12372,12373,12374 | 17408000 |
| 11 | fgedudb | fgedu_large_table | t_1003_20000000 | t_1003_30000000 | 12375 | 192.168.1.20 | 20160 | 12375,12376,12377 | 17408000 |
| 12 | fgedudb | fgedu_large_table | t_1003_30000000 | t_1003_40000000 | 12378 | 192.168.1.21 | 20160 | 12378,12379,12380 | 17408000 |
| 13 | fgedudb | fgedu_large_table | t_1003_40000000 | t_1003_50000000 | 12381 | 192.168.1.22 | 20160 | 12381,12382,12383 | 17408000 |
| 14 | fgedudb | fgedu_large_table | t_1003_50000000 | t_1003_7fffffff | 12384 | 192.168.1.20 | 20160 | 12384,12385,12386 | 17408000 |
+———–+———+—————-+———–+—————-+—————-+————+——————+——————+——————-+

## 6. 验证优化效果
– 查看Region数量：SELECT COUNT(*) FROM information_schema.tikv_region_status WHERE db_name = ‘fgedudb’ AND table_name = ‘fgedu_large_table’;
– 查看管理开销：top

4.3 均衡实战

4.3.1 Region均衡

# Region均衡

## 1. 问题：Region分布不均衡
– 现象：某个TiKV节点Region数量远多于其他节点
– 原因：PD调度策略需要调整
– 解决方案：调整PD调度参数，平衡Region分布

## 2. 查看Region分布
mysql> SELECT peer_store_id, COUNT(*) AS region_count
-> FROM information_schema.tikv_region_status
-> GROUP BY peer_store_id
-> ORDER BY region_count DESC;

# 输出示例
+————-+————–+
| peer_store_id | region_count |
+————-+————–+
| 1 | 1000 |
| 2 | 800 |
| 3 | 700 |
+————-+————–+

## 3. 调整PD调度参数
$ vim /tidb/app/pd/conf/pd.toml

[scheduler]
# 调整最大调度数量
max-schedule-count = 32
# 调整存储均衡阈值
store-balance-rate = 20

## 4. 重启PD
$ systemctl restart pd

## 5. 手动触发均衡
mysql> ADMIN SCHEDULER CONFIGURE balance-region, “{\”enable\”: true}”;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 6. 验证均衡效果
mysql> SELECT peer_store_id, COUNT(*) AS region_count
-> FROM information_schema.tikv_region_status
-> GROUP BY peer_store_id
-> ORDER BY region_count DESC;

# 输出示例
+————-+————–+
| peer_store_id | region_count |
+————-+————–+
| 1 | 833 |
| 2 | 833 |
| 3 | 834 |
+————-+————–+

## 7. 查看TiKV节点负载
– 查看CPU使用率：top
– 查看内存使用率：free -h
– 查看IO使用率：iostat -x 1

4.3.2 Leader均衡

# Leader均衡

## 1. 问题：Leader分布不均衡
– 现象：某个TiKV节点Leader数量远多于其他节点
– 原因：PD领导者调度策略需要调整
– 解决方案：调整PD领导者调度参数，平衡Leader分布

## 2. 查看Leader分布
mysql> SELECT leader_store_id, COUNT(*) AS leader_count
-> FROM information_schema.tikv_region_status
-> GROUP BY leader_store_id
-> ORDER BY leader_count DESC;

# 输出示例
+—————+————–+
| leader_store_id | leader_count |
+—————+————–+
| 1 | 600 |
| 2 | 400 |
| 3 | 300 |
+—————+————–+

## 3. 调整PD领导者调度参数
$ vim /tidb/app/pd/conf/pd.toml

[scheduler]
# 调整领导者调度限制
leader-schedule-limit = 8
# 调整领导者均衡阈值
leader-schedule-policy = “count”

## 4. 重启PD
$ systemctl restart pd

## 5. 手动触发领导者均衡
mysql> ADMIN SCHEDULER CONFIGURE balance-leader, “{\”enable\”: true}”;

# 输出示例
Query OK, 0 rows affected (0.01 sec)

## 6. 验证均衡效果
mysql> SELECT leader_store_id, COUNT(*) AS leader_count
-> FROM information_schema.tikv_region_status
-> GROUP BY leader_store_id
-> ORDER BY leader_count DESC;

# 输出示例
+—————+————–+
| leader_store_id | leader_count |
+—————+————–+
| 1 | 433 |
| 2 | 433 |
| 3 | 434 |
+—————+————–+

## 7. 查看TiKV节点负载
– 查看CPU使用率：top
– 查看内存使用率：free -h
– 查看IO使用率：iostat -x 1

生产环境建议：在进行Region均衡时，需要根据系统负载和业务需求调整调度参数，避免过度调度影响系统性能。

Part05-风哥经验总结与分享

5.1 最佳实践

最佳实践：

  • 分裂策略选择：根据表的大小和访问模式选择合适的分裂策略，大表可以设置更大的分裂阈值，热点表可以使用基于热点的分裂
  • 合并策略选择：对于小Region和删除数据后的表，及时合并Region，减少管理开销
  • 均衡策略选择：根据集群状态选择合适的均衡策略，系统负载高时减少调度，业务高峰期减少调度
  • 参数调优：根据集群规模和硬件配置调整分裂、合并和均衡参数，确保系统性能
  • 监控与告警：建立完善的监控体系，及时发现和处理Region相关问题
  • 定期维护：定期检查表的Region分布，清理无用数据，优化性能
  • 性能测试：在上线前进行充分的性能测试，发现和解决潜在问题
  • 备份与恢复：定期备份数据，确保数据安全

5.2 常见问题与解决方案

常见问题与解决方案：

# 常见问题与解决方案

## 1. 热点Region
– 问题：某个Region成为热点，导致TiKV节点负载过高
– 解决方案：
– 手动分裂热点Region
– 优化SQL语句，避免热点写入
– 使用分散的主键，避免顺序写入
– 调整PD热点调度参数

## 2. Region分裂频繁
– 问题：Region分裂过于频繁，影响性能
– 解决方案：
– 调整Region分裂大小阈值
– 优化表结构，避免大表
– 合理设置分裂策略

## 3. Region合并失败
– 问题：相邻Region无法自动合并
– 解决方案：
– 调整Region合并大小阈值
– 手动合并Region
– 检查Region状态，确保Region正常

## 4. Region分布不均衡
– 问题：Region集中在少数TiKV节点，导致负载不均衡
– 解决方案：
– 调整PD均衡调度参数
– 重启PD，触发重新调度
– 手动迁移Region

## 5. Leader分布不均衡
– 问题：Leader集中在少数TiKV节点，导致负载不均衡
– 解决方案：
– 调整PD领导者调度参数
– 手动触发领导者均衡
– 检查TiKV节点状态，确保节点正常

## 6. 调度开销过大
– 问题：PD调度过于频繁，影响系统性能
– 解决方案：
– 调整PD调度参数，减少调度频率
– 在业务高峰期禁用调度
– 优化集群拓扑，减少调度需求

5.3 性能调优技巧

# 性能调优技巧

## 1. 分裂调优
– 合理设置Region分裂大小：根据表的大小和访问模式调整
– 手动分裂热点Region：提前分裂热点Region，分散热点
– 批量分裂大表：对于大表，批量分裂Region，提高查询性能

## 2. 合并调优
– 及时合并小Region：减少管理开销
– 合理设置合并阈值：根据实际情况调整合并阈值
– 避开业务高峰期合并：减少对业务的影响

## 3. 均衡调优
– 调整PD调度参数：根据集群规模和负载调整
– 手动触发均衡：在集群拓扑变化后手动触发均衡
– 监控均衡效果：及时发现和处理均衡问题

## 4. 硬件调优
– 使用高性能存储：如SSD，提高Region分裂和合并的速度
– 增加网络带宽：提高Region迁移的速度
– 优化服务器配置：根据集群规模选择合适的服务器配置

## 5. 业务调优
– 优化SQL语句：避免全表扫描和大事务
– 合理设计表结构：避免大表和热点数据
– 错峰处理：避开业务高峰期进行批量操作
– 数据分片：将大表分成多个小表，减少Region大小

## 6. 监控调优
– 建立完善的监控体系：及时发现和处理Region相关问题
– 设置合理的告警阈值：避免告警风暴
– 分析监控数据：根据监控数据优化系统配置

风哥提示：TiDB的Region分裂、合并与均衡是系统性能的关键因素，需要根据业务需求和系统实际情况进行合理规划和优化。建议定期进行性能评估和优化，确保系统能够满足业务的需求。

持续改进：Region分裂、合并与均衡是一个持续的过程，需要根据系统的变化和业务的增长不断调整和改进。建议建立完善的管理体系，及时发现和处理相关问题，确保系统的性能和稳定性。

本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html

相关推荐

联系我们

在线咨询：点击这里给我发消息

微信号：itpux-com

工作日：9:30-18:30，节假日休息