1. 项目概述
在视频管理系统的数据库设计中，我们经常会遇到单表数据量过大的性能瓶颈问题。最近我在一个视频点播平台的项目中，就遇到了播放记录表超过3000万条数据后查询明显变慢的情况。经过多种方案对比，最终选择使用MySQL 5.7的表分区功能来解决这个问题。
表分区（Partitioning）是MySQL提供的一种将大表物理分割为多个小表的技术，它能显著提升大表的查询和维护效率。不同于分表的是，分区表在逻辑上仍然是一个表，对应用层完全透明，不需要修改业务代码。
2. 核心需求解析
2.1 视频系统的典型数据特点
视频系统中最常见的两类大表是：
- 视频元数据表（video_metadata）
- 用户播放记录表（playback_history）
以播放记录表为例，它通常包含以下字段：
- 记录ID（自增主键）
- 用户ID
- 视频ID
- 播放开始时间
- 播放时长
- 设备信息
- 网络类型等
这类表的特点是：
- 数据增长快（每天新增数十万条）
- 查询通常按时间范围过滤
- 历史数据很少修改但需要保留
- 热数据集中在最近时间段
2.2 分区策略选择
针对播放记录表，我们选择了RANGE分区（按时间范围分区），这是视频系统中最常用的分区类型。每个分区存储一个月的数据，这样：
- 查询最近数据时只需扫描1-2个分区
- 可以快速删除过期数据（直接删除整个分区）
- 备份和统计可以按分区进行
3. 分区表设计与实现
3.1 创建分区表
以下是播放记录表的分区创建SQL：
sql复制CREATE TABLE playback_history (
id BIGINT NOT NULL AUTO_INCREMENT,
user_id INT NOT NULL,
video_id INT NOT NULL,
play_time DATETIME NOT NULL,
duration INT NOT NULL,
device VARCHAR(50),
network_type VARCHAR(20),
PRIMARY KEY (id, play_time)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(play_time)) (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
PARTITION p202303 VALUES LESS THAN (TO_DAYS('2023-04-01')),
PARTITION p202304 VALUES LESS THAN (TO_DAYS('2023-05-01')),
PARTITION p202305 VALUES LESS THAN (TO_DAYS('2023-06-01')),
PARTITION p202306 VALUES LESS THAN (TO_DAYS('2023-07-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
关键点说明：
- 分区键必须包含在主键中（这就是为什么主键是(id, play_time)）
- 使用TO_DAYS函数将日期转换为天数进行范围比较
- 最后一个分区使用MAXVALUE容纳未来的数据
- 每个分区对应一个月的播放记录
3.2 分区维护操作
3.2.1 添加新分区
每月初需要添加新的分区：
sql复制ALTER TABLE playback_history REORGANIZE PARTITION pmax INTO (
PARTITION p202307 VALUES LESS THAN (TO_DAYS('2023-08-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
3.2.2 删除旧分区
当数据过期后（比如保留12个月数据），可以删除最早的分区：
sql复制ALTER TABLE playback_history DROP PARTITION p202301;
注意：删除分区会同时删除该分区中的所有数据，且无法恢复。执行前请确认数据已备份或不再需要。
3.2.3 分区数据归档
如果需要保留历史数据但不希望影响性能，可以将分区数据导出：
sql复制-- 创建归档表（结构相同但不分区）
CREATE TABLE playback_history_archive LIKE playback_history;
ALTER TABLE playback_history_archive REMOVE PARTITIONING;
-- 将分区数据交换到归档表
ALTER TABLE playback_history EXCHANGE PARTITION p202301
WITH TABLE playback_history_archive;
4. 查询优化实践
4.1 分区裁剪（Partition Pruning）
MySQL会自动优化查询，只扫描必要的分区。例如：
sql复制-- 只扫描p202304分区
SELECT * FROM playback_history
WHERE play_time BETWEEN '2023-04-15' AND '2023-04-20';
-- 只扫描p202303和p202304分区
SELECT COUNT(*) FROM playback_history
WHERE play_time BETWEEN '2023-03-25' AND '2023-04-05';
可以通过EXPLAIN查看分区使用情况：
sql复制EXPLAIN PARTITIONS
SELECT * FROM playback_history
WHERE play_time BETWEEN '2023-04-01' AND '2023-04-30';
4.2 避免全分区扫描
以下情况会导致全分区扫描，应尽量避免：
-
在非分区键上过滤：
sql复制-- 全分区扫描（user_id不是分区键） SELECT * FROM playback_history WHERE user_id = 1001; -
使用函数或运算：
sql复制-- 全分区扫描（使用了DATE_FORMAT函数） SELECT * FROM playback_history WHERE DATE_FORMAT(play_time, '%Y-%m') = '2023-04'; -
未包含分区键的JOIN条件：
sql复制-- 全分区扫描 SELECT * FROM playback_history ph JOIN videos v ON ph.video_id = v.id;
优化方案是为这些查询添加分区键条件或创建合适的索引。
5. 性能对比测试
我们在测试环境对分区表和非分区表进行了对比测试（3000万条数据）：
| 测试场景 | 非分区表耗时 | 分区表耗时 | 提升倍数 |
|---|---|---|---|
| 查询单月数据 | 1.8s | 0.2s | 9x |
| 统计单月播放量 | 2.3s | 0.3s | 7.6x |
| 删除整月数据 | 12.4s | 0.01s | 1240x |
| 备份单月数据 | 需要全表备份 | 可单独备份分区 | N/A |
6. 常见问题与解决方案
6.1 分区键选择不当
问题现象：选择了低区分度的列作为分区键（如性别、状态等），导致分区效果不佳。
解决方案：
- 选择高区分度且常用于查询条件的列
- 视频系统中最常用的是时间字段（create_time, update_time等）
- 也可以考虑使用用户ID哈希分区（对用户维度查询多的场景）
6.2 分区数量过多
问题现象：创建了过多分区（如按天分区导致数百个分区），导致：
- 打开表变慢
- 内存消耗增加
- 某些文件系统对单个目录文件数有限制
解决方案：
- 控制分区数量在50-100个以内
- 视频系统通常按月分区即可
- 对特别热的表可以考虑按周分区
6.3 跨分区查询性能差
问题现象：查询条件跨多个分区，性能提升不明显。
解决方案：
- 尽量优化查询条件，利用分区裁剪
- 对跨分区查询创建合适的索引
- 考虑使用子分区（MySQL 5.7支持）
6.4 唯一键限制
问题现象：所有唯一索引必须包含分区键。
解决方案：
- 调整唯一索引定义，包含分区键
- 或者使用应用层保证唯一性
7. 进阶技巧
7.1 子分区（Subpartitioning）
对于特别大的表，可以使用子分区进一步细分。例如按月分区，再按用户ID哈希子分区：
sql复制CREATE TABLE playback_history (
id BIGINT NOT NULL AUTO_INCREMENT,
user_id INT NOT NULL,
-- 其他字段...
PRIMARY KEY (id, play_time, user_id)
) ENGINE=InnoDB
PARTITION BY RANGE (TO_DAYS(play_time))
SUBPARTITION BY HASH(user_id)
SUBPARTITIONS 4 (
PARTITION p202301 VALUES LESS THAN (TO_DAYS('2023-02-01')),
PARTITION p202302 VALUES LESS THAN (TO_DAYS('2023-03-01')),
PARTITION pmax VALUES LESS THAN MAXVALUE
);
7.2 分区与索引结合优化
合理的索引设计可以进一步提升分区表性能：
- 本地索引（每个分区独立的索引）
- 全局索引（跨分区的索引，MySQL 5.7不支持原生全局索引，但可以通过以下方式模拟）：
sql复制-- 在分区键上创建索引
ALTER TABLE playback_history ADD INDEX idx_play_time (play_time);
-- 在常用查询条件上创建复合索引
ALTER TABLE playback_history ADD INDEX idx_user_play (user_id, play_time);
7.3 分区表监控
通过以下SQL监控分区使用情况：
sql复制-- 查看分区数据分布
SELECT PARTITION_NAME, TABLE_ROWS
FROM INFORMATION_SCHEMA.PARTITIONS
WHERE TABLE_NAME = 'playback_history';
-- 查看分区存储空间
SELECT partition_name, data_length/1024/1024 as size_mb
FROM information_schema.partitions
WHERE table_name = 'playback_history';
8. 实战经验分享
在实际项目中应用分区表时，我总结了以下几点经验：
-
分区规划要提前：最好在表设计阶段就考虑分区策略，后期从普通表转为分区表成本较高（需要重建表）。
-
分区大小要均衡：尽量保持各分区数据量相近，避免出现"热分区"。视频系统中，按月分区通常比较均衡。
-
维护窗口要预留：添加/删除分区、重组分区等操作会锁表，应在低峰期执行。
-
监控要及时：设置监控及时发现分区已满或需要维护的情况。
-
备份策略要调整：可以按分区进行备份，减少每次备份的数据量。
-
应用层要适配：虽然分区表对应用透明，但针对分区特性优化查询可以进一步提升性能。
在视频系统这个具体场景中，表分区带来了显著的性能提升：
- 播放记录查询响应时间从秒级降到毫秒级
- 月度统计报表生成时间从分钟级降到秒级
- 历史数据清理时间从天级降到秒级
- 存储空间节省约30%（通过压缩旧分区）
最后提醒一点：分区不是银弹，它最适合"时间序列数据"和"有明显冷热区分"的场景。对于其他场景，可能需要考虑分库分表或其他优化方案。