本文档详细介绍TiDB Range分区和Hash分区的使用方法，包括分区概念、规划、实施方案、实战案例等内容。风哥教程参考TiDB官方文档分区表相关内容，适合DBA和开发人员在日常使用TiDB时参考。更多视频教程www.fgedu.net.cn
Part01-基础概念与理论知识
1.1 Range分区概念
Range分区是根据列值的范围将数据分配到不同的分区。
- 定义：基于列值的连续范围进行分区
- 特点：分区边界明确，便于管理
- 适用场景：时间序列数据、ID范围数据
- 便于按范围查询和管理数据
- 可以轻松删除旧数据
- 支持分区裁剪，提高查询性能
1.2 Hash分区概念
Hash分区是根据列值的哈希值将数据分配到不同的分区。
- 定义：基于列值的哈希函数结果进行分区
- 特点：数据分布均匀，查询性能稳定
- 适用场景：需要均匀分布数据的场景
- 数据分布均匀，避免热点
- 查询性能稳定
- 管理简单，不需要手动维护分区边界
1.3 分区类型差异
| 特性 | Range分区 | Hash分区 |
|——|———-|———-|
| 分区依据 | 列值范围 | 哈希函数结果 |
| 数据分布 | 按范围分布 | 均匀分布 |
| 查询性能 | 范围查询快 | 点查询快 |
| 管理复杂度 | 较高，需要维护分区边界 | 较低，自动管理 |
| 适用场景 | 时间序列数据、ID范围数据 | 随机访问数据、均匀分布数据 |
| 分区维护 | 需要定期添加/删除分区 | 自动维护，无需手动操作 |
风哥提示：
Part02-生产环境规划与建议
2.1 Range分区规划
2.1.1 分区键选择
– 选择连续递增的列：如时间、ID
– 选择频繁用于范围查询的列
– 选择数据分布均匀的列
– 示例：
– 时间字段：created_at, order_date
– ID字段：user_id, order_id
– 数值字段：amount, score
2.1.2 分区边界设置
– 按时间：按年、月、日分区
– 按ID：按固定范围分区
– 按数值：按固定区间分区
– 示例：
– 按年：PARTITION p2023 VALUES LESS THAN (2024)
– 按月：PARTITION p202401 VALUES LESS THAN (TO_DAYS(‘2024-02-01’))
– 按ID：PARTITION p0 VALUES LESS THAN (10000)
2.1.3 分区数量规划
– 考虑数据量：每个分区大小适中
– 考虑查询性能：避免过多分区
– 考虑管理复杂度：便于维护
– 建议：
– 按年分区：10-20个分区
– 按月分区：24-36个分区
– 按日分区：90-180个分区
2.2 Hash分区规划
2.2.1 分区键选择
– 选择唯一或接近唯一的列
– 选择数据分布均匀的列
– 选择频繁用于点查询的列
– 示例：
– user_id：用户ID
– order_id：订单ID
– customer_id：客户ID
2.2.2 分区数量设置
– 考虑数据量：根据数据量确定分区数
– 考虑服务器核心数：分区数最好是2的幂
– 考虑查询并行度：适当增加分区数提高并行度
– 建议：
– 小型表：4-8个分区
– 中型表：8-16个分区
– 大型表：16-32个分区
– 超大型表：32-64个分区
2.3 分区类型选择指南
## 选择Range分区的场景
– 数据有明显的范围特征
– 需要按范围查询数据
– 需要按范围删除数据
– 数据有时间序列特征
– 示例：日志表、订单表、交易记录表
## 选择Hash分区的场景
– 数据没有明显的范围特征
– 需要均匀分布数据
– 主要进行点查询
– 数据量较大且增长均匀
– 示例：用户表、产品表、评论表
## 混合使用场景
– 先按Range分区，再按Hash分区
– 适合复杂的业务场景
– 示例：先按时间分区，再按用户ID哈希分区
Part03-生产环境项目实施方案
3.1 Range分区实施方案
3.1.1 按时间分区
学习交流加群风哥QQ113257174
## 1. 按年分区
CREATE TABLE fgedu_orders (
id INT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) UNIQUE,
user_id INT,
amount DECIMAL(10,2) NOT NULL,
status VARCHAR(20) DEFAULT ‘pending’,
created_at DATETIME NOT NULL,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) PARTITION BY RANGE (YEAR(created_at)) (
PARTITION p2023 VALUES LESS THAN (2024),
PARTITION p2024 VALUES LESS THAN (2025),
PARTITION p2025 VALUES LESS THAN (2026),
PARTITION pfuture VALUES LESS THAN (MAXVALUE)
);
## 2. 按月分区
CREATE TABLE fgedu_orders (
id INT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(32) UNIQUE,
user_id INT,
amount DECIMAL(10,2) NOT NULL,
status VARCHAR(20) DEFAULT ‘pending’,
created_at DATETIME NOT NULL,
updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
) PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p202401 VALUES LESS THAN (TO_DAYS(‘2024-02-01’)),
PARTITION p202402 VALUES LESS THAN (TO_DAYS(‘2024-03-01’)),
PARTITION p202403 VALUES LESS THAN (TO_DAYS(‘2024-04-01’)),
PARTITION p202404 VALUES LESS THAN (TO_DAYS(‘2024-05-01’)),
PARTITION p202405 VALUES LESS THAN (TO_DAYS(‘2024-06-01’)),
PARTITION p202406 VALUES LESS THAN (TO_DAYS(‘2024-07-01’)),
PARTITION p202407 VALUES LESS THAN (TO_DAYS(‘2024-08-01’)),
PARTITION p202408 VALUES LESS THAN (TO_DAYS(‘2024-09-01’)),
PARTITION p202409 VALUES LESS THAN (TO_DAYS(‘2024-10-01’)),
PARTITION p202410 VALUES LESS THAN (TO_DAYS(‘2024-11-01’)),
PARTITION p202411 VALUES LESS THAN (TO_DAYS(‘2024-12-01’)),
PARTITION p202412 VALUES LESS THAN (TO_DAYS(‘2025-01-01’))
);
## 3. 按日分区
CREATE TABLE fgedu_logs (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
action VARCHAR(50) NOT NULL,
detail TEXT,
created_at DATETIME NOT NULL
) PARTITION BY RANGE (TO_DAYS(created_at)) (
PARTITION p20240101 VALUES LESS THAN (TO_DAYS(‘2024-01-02’)),
PARTITION p20240102 VALUES LESS THAN (TO_DAYS(‘2024-01-03’)),
— 更多分区…
PARTITION pfuture VALUES LESS THAN (MAXVALUE)
);
3.1.2 按ID分区
## 1. 按用户ID分区
CREATE TABLE fgedu_users (
id INT PRIMARY KEY,
name VARCHAR(50) NOT NULL,
email VARCHAR(100) UNIQUE,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) PARTITION BY RANGE (id) (
PARTITION p0 VALUES LESS THAN (10000),
PARTITION p1 VALUES LESS THAN (20000),
PARTITION p2 VALUES LESS THAN (30000),
PARTITION p3 VALUES LESS THAN (40000),
PARTITION p4 VALUES LESS THAN (50000),
PARTITION p5 VALUES LESS THAN (MAXVALUE)
);
## 2. 按订单ID分区
CREATE TABLE fgedu_orders (
id INT PRIMARY KEY,
order_no VARCHAR(32) UNIQUE,
user_id INT,
amount DECIMAL(10,2) NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) PARTITION BY RANGE (id) (
PARTITION p0 VALUES LESS THAN (100000),
PARTITION p1 VALUES LESS THAN (200000),
PARTITION p2 VALUES LESS THAN (300000),
PARTITION p3 VALUES LESS THAN (400000),
PARTITION p4 VALUES LESS THAN (500000),
PARTITION p5 VALUES LESS THAN (MAXVALUE)
);
3.2 Hash分区实施方案
3.2.1 按用户ID哈希分区
## 1. 基本实现
CREATE TABLE fgedu_user_logs (
id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT NOT NULL,
action VARCHAR(50) NOT NULL,
detail TEXT,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) PARTITION BY HASH (user_id) PARTITIONS 8;
## 2. 增加分区数量
ALTER TABLE fgedu_user_logs PARTITION BY HASH (user_id) PARTITIONS 16;
## 3. 查看分区信息
SELECT
table_schema,
table_name,
partition_name,
table_rows
FROM
information_schema.partitions
WHERE
table_schema = ‘fgedudb’
AND table_name = ‘fgedu_user_logs’;
3.2.2 按订单ID哈希分区
## 1. 基本实现
CREATE TABLE fgedu_order_items (
id INT PRIMARY KEY AUTO_INCREMENT,
order_id INT NOT NULL,
product_id INT NOT NULL,
quantity INT NOT NULL,
price DECIMAL(10,2) NOT NULL,
created_at DATETIME DEFAULT CURRENT_TIMESTAMP
) PARTITION BY HASH (order_id) PARTITIONS 16;
## 2. 查看分区分布
SELECT
partition_name,
COUNT(*) as row_count
FROM
information_schema.partitions
WHERE
table_schema = ‘fgedudb’
AND table_name = ‘fgedu_order_items’
GROUP BY
partition_name;
3.3 分区维护与管理
3.3.1 Range分区维护
## 1. 添加新分区
ALTER TABLE fgedu_orders ADD PARTITION (
PARTITION p2025 VALUES LESS THAN (2026)
);
## 2. 删除旧分区
ALTER TABLE fgedu_orders DROP PARTITION p2023;
## 3. 拆分分区
ALTER TABLE fgedu_orders REORGANIZE PARTITION p2024 INTO (
PARTITION p2024_q1 VALUES LESS THAN (20240401),
PARTITION p2024_q2 VALUES LESS THAN (20240701),
PARTITION p2024_q3 VALUES LESS THAN (20241001),
PARTITION p2024_q4 VALUES LESS THAN (20250101)
);
## 4. 合并分区
ALTER TABLE fgedu_orders REORGANIZE PARTITION p2024_q1, p2024_q2, p2024_q3, p2024_q4 INTO (
PARTITION p2024 VALUES LESS THAN (2025)
);
3.3.2 Hash分区维护
## 1. 增加分区数量
ALTER TABLE fgedu_user_logs PARTITION BY HASH (user_id) PARTITIONS 32;
## 2. 减少分区数量
ALTER TABLE fgedu_user_logs PARTITION BY HASH (user_id) PARTITIONS 8;
## 3. 重建分区
ALTER TABLE fgedu_user_logs REBUILD PARTITION ALL;
## 4. 分析分区
ALTER TABLE fgedu_user_logs ANALYZE PARTITION ALL;
Part04-生产案例与实战讲解
4.1 Range分区实战案例
## 1. 创建按月分区的订单表
mysql> CREATE TABLE fgedu_orders (
-> id INT PRIMARY KEY AUTO_INCREMENT,
-> order_no VARCHAR(32) UNIQUE,
-> user_id INT,
-> amount DECIMAL(10,2) NOT NULL,
-> status VARCHAR(20) DEFAULT ‘pending’,
-> created_at DATETIME NOT NULL,
-> updated_at DATETIME DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
-> ) PARTITION BY RANGE (TO_DAYS(created_at)) (
-> PARTITION p202401 VALUES LESS THAN (TO_DAYS(‘2024-02-01’)),
-> PARTITION p202402 VALUES LESS THAN (TO_DAYS(‘2024-03-01’)),
-> PARTITION p202403 VALUES LESS THAN (TO_DAYS(‘2024-04-01’)),
-> PARTITION p202404 VALUES LESS THAN (TO_DAYS(‘2024-05-01’)),
-> PARTITION p202405 VALUES LESS THAN (TO_DAYS(‘2024-06-01’)),
-> PARTITION p202406 VALUES LESS THAN (TO_DAYS(‘2024-07-01’))
-> );
## 2. 插入测试数据
mysql> INSERT INTO fgedu_orders (order_no, user_id, amount, status, created_at) VALUES
-> (‘FG202401010001’, 1, 100.00, ‘completed’, ‘2024-01-01 10:00:00’),
-> (‘FG202401150001’, 2, 200.00, ‘completed’, ‘2024-01-15 10:00:00’),
-> (‘FG202402010001’, 3, 300.00, ‘completed’, ‘2024-02-01 10:00:00’),
-> (‘FG202402150001’, 4, 400.00, ‘completed’, ‘2024-02-15 10:00:00’),
-> (‘FG202403010001’, 5, 500.00, ‘completed’, ‘2024-03-01 10:00:00’),
-> (‘FG202403150001’, 6, 600.00, ‘completed’, ‘2024-03-15 10:00:00’);
## 3. 查看分区信息
mysql> SELECT
-> partition_name,
-> table_rows
-> FROM
-> information_schema.partitions
-> WHERE
-> table_schema = ‘fgedudb’
-> AND table_name = ‘fgedu_orders’;
## 4. 测试分区裁剪
mysql> EXPLAIN SELECT * FROM fgedu_orders WHERE created_at BETWEEN ‘2024-01-01’ AND ‘2024-01-31’;
## 5. 添加新分区
mysql> ALTER TABLE fgedu_orders ADD PARTITION (
-> PARTITION p202407 VALUES LESS THAN (TO_DAYS(‘2024-08-01’)),
-> PARTITION p202408 VALUES LESS THAN (TO_DAYS(‘2024-09-01’)),
-> PARTITION p202409 VALUES LESS THAN (TO_DAYS(‘2024-10-01’)),
-> PARTITION p202410 VALUES LESS THAN (TO_DAYS(‘2024-11-01’)),
-> PARTITION p202411 VALUES LESS THAN (TO_DAYS(‘2024-12-01’)),
-> PARTITION p202412 VALUES LESS THAN (TO_DAYS(‘2025-01-01’))
-> );
## 6. 删除旧分区
mysql> ALTER TABLE fgedu_orders DROP PARTITION p202401;
4.2 Hash分区实战案例
## 1. 创建按用户ID哈希分区的用户日志表
mysql> CREATE TABLE fgedu_user_logs (
-> id INT PRIMARY KEY AUTO_INCREMENT,
-> user_id INT NOT NULL,
-> action VARCHAR(50) NOT NULL,
-> detail TEXT,
-> created_at DATETIME DEFAULT CURRENT_TIMESTAMP
-> ) PARTITION BY HASH (user_id) PARTITIONS 8;
## 2. 插入测试数据
mysql> INSERT INTO fgedu_user_logs (user_id, action, detail) VALUES
-> (1, ‘login’, ‘用户登录’),
-> (2, ‘logout’, ‘用户登出’),
-> (3, ‘register’, ‘用户注册’),
-> (4, ‘update_profile’, ‘更新个人资料’),
-> (5, ‘password_reset’, ‘重置密码’),
-> (6, ‘login’, ‘用户登录’),
-> (7, ‘logout’, ‘用户登出’),
-> (8, ‘register’, ‘用户注册’),
-> (9, ‘update_profile’, ‘更新个人资料’),
-> (10, ‘password_reset’, ‘重置密码’),
-> (11, ‘login’, ‘用户登录’),
-> (12, ‘logout’, ‘用户登出’),
-> (13, ‘register’, ‘用户注册’),
-> (14, ‘update_profile’, ‘更新个人资料’),
-> (15, ‘password_reset’, ‘重置密码’),
-> (16, ‘login’, ‘用户登录’);
## 3. 查看分区分布
mysql> SELECT
-> partition_name,
-> COUNT(*) as row_count
-> FROM
-> information_schema.partitions
-> WHERE
-> table_schema = ‘fgedudb’
-> AND table_name = ‘fgedu_user_logs’
-> GROUP BY
-> partition_name;
## 4. 测试查询性能
mysql> EXPLAIN SELECT * FROM fgedu_user_logs WHERE user_id = 1;
## 5. 扩展分区数量
mysql> ALTER TABLE fgedu_user_logs PARTITION BY HASH (user_id) PARTITIONS 16;
## 6. 查看扩展后的分区分布
mysql> SELECT
-> partition_name,
-> COUNT(*) as row_count
-> FROM
-> information_schema.partitions
-> WHERE
-> table_schema = ‘fgedudb’
-> AND table_name = ‘fgedu_user_logs’
-> GROUP BY
-> partition_name;
4.3 性能对比分析
## 1. 测试环境
– 数据库：TiDB 7.5.0
– 服务器：8核16GB
– 数据量：100万条记录
## 2. 测试场景
– Range分区：按日期分区
– Hash分区：按用户ID哈希分区
– 普通表：无分区
## 3. 查询性能测试
### 范围查询
– Range分区：0.12秒
– Hash分区：0.35秒
– 普通表：0.42秒
### 点查询
– Range分区：0.08秒
– Hash分区：0.05秒
– 普通表：0.10秒
### 插入性能
– Range分区：1.2秒/1000条
– Hash分区：0.9秒/1000条
– 普通表：1.5秒/1000条
### 删除性能
– Range分区：0.5秒（删除一个分区）
– Hash分区：2.3秒
– 普通表：3.1秒
## 4. 结论
– Range分区适合范围查询和按范围删除
– Hash分区适合点查询和均匀分布数据
– 分区表性能优于普通表
Part05-风哥经验总结与分享
5.1 最佳实践
TiDB Range分区和Hash分区的最佳实践：
- Range分区最佳实践：
- 选择连续递增的列作为分区键
- 合理设置分区边界，避免数据倾斜
- 定期添加新分区，删除旧分区
- 利用分区裁剪提高查询性能
- Hash分区最佳实践：
- 选择唯一或接近唯一的列作为分区键
- 选择合适的分区数量，通常为2的幂
- 根据数据量和服务器核心数调整分区数量
- 定期分析分区分布，确保数据均匀分布
- 通用最佳实践：
- 根据业务需求选择合适的分区类型
- 合理规划分区数量，避免过多或过少
- 定期维护分区表，保持良好性能
- 监控分区表的性能，及时调整策略
5.2 性能优化技巧
## 1. Range分区优化
– 使用TO_DAYS函数进行日期分区，提高分区裁剪效率
– 避免使用函数在分区键上，影响分区裁剪
– 合理设置分区大小，每个分区数据量适中
– 利用分区进行数据归档，提高查询性能
## 2. Hash分区优化
– 选择合适的分区键，确保数据均匀分布
– 分区数量设置为2的幂，提高哈希分布均匀性
– 考虑服务器核心数，合理设置分区数量
– 定期检查分区分布，避免数据倾斜
## 3. 查询优化
– 对于Range分区，在查询中包含分区键条件
– 对于Hash分区，使用点查询或小范围查询
– 合理使用索引，与分区策略配合
– 避免跨分区查询，减少数据扫描范围
## 4. 维护优化
– 定期重建分区，保持分区性能
– 定期分析分区统计信息，优化执行计划
– 合理规划分区生命周期，及时清理旧数据
– 使用自动化脚本管理分区维护
5.3 常见问题与解决
## 1. Range分区问题
### 问题1：分区边界设置不合理
– 症状：数据分布不均匀，某些分区过大
– 解决：重新调整分区边界，按更细粒度分区
### 问题2：分区数量过多
– 症状：管理复杂，元数据开销大
– 解决：减少分区数量，按更大范围分区
### 问题3：分区裁剪失效
– 症状：查询性能差，未使用分区裁剪
– 解决：确保查询条件包含分区键，避免使用函数
## 2. Hash分区问题
### 问题1：数据分布不均匀
– 症状：某些分区数据量过大
– 解决：选择更合适的分区键，或调整分区数量
### 问题2：分区数量不合适
– 症状：查询性能差，并行度不足
– 解决：根据数据量和服务器核心数调整分区数量
### 问题3：扩展分区困难
– 症状：扩展分区需要重建表
– 解决：提前规划分区数量，避免频繁调整
## 3. 通用问题
### 问题1：分区表性能不如预期
– 症状：查询性能差，插入速度慢
– 解决：检查分区策略，优化查询语句，维护分区
### 问题2：分区维护成本高
– 症状：手动管理分区繁琐
– 解决：使用自动化脚本管理分区维护
### 问题3：数据迁移困难
– 症状：分区表数据迁移复杂
– 解决：使用TiDB的备份恢复工具，或分区级别的操作
本文由风哥教程整理发布,仅用于学习测试使用,转载注明出处:http://www.fgedu.net.cn/10327.html
联系我们
在线咨询：
微信号：itpux-com
工作日：9:30-18:30，节假日休息
