一、分区表基础：什么是分区表、核心优势与分区键选择

各位好，我是老赵。今天咱们聊聊分区表。说实话，我见过太多人把分区表当成"银弹"——以为分了区就万事大吉。结果呢？查询反而更慢了。所以这一章，咱们先把基础打牢。

1.1 什么是分区表

分区表，说白了就是把一张大表，按某种规则拆成多个物理小表。但对应用层来说，它还是一张表。你查数据时，SQL 还是写 SELECT * FROM orders，但数据库内部只扫描相关分区。

举个例子。我手头有个订单表，一年 5 亿条数据。没分区时，查某一天的订单，也得扫全表。分区后，按天拆成 365 个小表，查某一天只扫一个分区。速度能差两个数量级。

常见的分区方式有四种：

分区类型	适用场景	我见过的坑
范围分区	时间、数值区间	边界值没处理好，数据跑错分区
列表分区	地区、状态码等枚举值	新值出现时没加分区，直接报错
哈希分区	均匀分布、无自然分区键	扩容时数据要重分布，代价大
复合分区	先范围再哈希/列表	分区数太多，管理成本飙升

1.2 分区表的核心优势

为什么要用分区表？我总结三个最实在的好处。

第一，查询性能提升。 这是最直接的。分区裁剪（Partition Pruning）能让优化器只扫必要分区。我做过一个压测：10 亿行数据，全表扫描要 47 秒，分区裁剪后只要 0.3 秒。你想想看，这差距有多大。

第二，维护操作更快。 删历史数据时，不用跑 DELETE 慢慢删。直接 DROP PARTITION，秒级完成。我曾经帮一个客户做数据归档，他们之前删一个月的数据要跑 6 小时。改成按周分区后，删除操作变成 0.5 秒。

第三，数据管理更灵活。 你可以把热分区放 SSD，冷分区放 HDD。还能单独备份某个分区，不用每次都全量备份。

1.3 分区键的选择原则

分区键选不好，分区表就是个摆设。我见过太多反面教材了。

原则一：选择查询条件中最常用的列。 分区裁剪依赖查询条件。如果你的 WHERE 条件里从来不出现分区键，那分区等于没分。比如订单表，90% 的查询都带时间范围，那就按时间分区。

原则二：保证数据分布相对均匀。 哈希分区尤其要注意。我曾经接手过一个系统，用用户 ID 做哈希分区。结果前 10% 的用户占了 80% 的数据，导致某些分区特别大，某些分区特别小。查询时，大分区还是慢。

原则三：分区数不要太多。 很多新手觉得分区越多越好。其实不然。分区数太多，元数据管理开销大，查询计划生成也慢。我个人建议，单表分区数控制在 1000 以内。如果超过 2000，就要考虑重新设计了。

原则四：考虑未来扩展性。 范围分区要预留好边界。比如按年分区，别只分到今年。万一明年系统还在用，你又得改分区定义。我习惯一次性分好未来 3-5 年的分区。

1.4 分区表的核心逻辑图

下面这张图，帮你理清分区表的核心逻辑。从分区键选择到分区裁剪，再到性能收益，一条线串起来。

1.5 分区表 vs 普通表：关键差异

我整理了一张对比表，方便你快速理解两者的区别。

维度	普通表	分区表
物理存储	一个表空间	多个分区，可分布在不同表空间
查询扫描	全表扫描	分区裁剪后只扫相关分区
数据删除	DELETE 逐行删除	DROP PARTITION 秒级删除
索引维护	全局索引	可建局部索引，维护成本低
备份恢复	全量备份	可单独备份/恢复某个分区
管理复杂度	低	中等，需规划分区策略

1.6 一个简单的分区表示例

光说不练假把式。咱们看个实际例子。假设有一个订单表，按月份分区。

-- 创建分区表（按月范围分区）
CREATE TABLE orders (
    order_id      NUMBER,
    order_date    DATE,
    customer_id   NUMBER,
    amount        NUMBER
)
PARTITION BY RANGE (order_date) (
    PARTITION p_2024_01 VALUES LESS THAN (TO_DATE('2024-02-01','YYYY-MM-DD')),
    PARTITION p_2024_02 VALUES LESS THAN (TO_DATE('2024-03-01','YYYY-MM-DD')),
    PARTITION p_2024_03 VALUES LESS THAN (TO_DATE('2024-04-01','YYYY-MM-DD')),
    PARTITION p_future  VALUES LESS THAN (MAXVALUE)
);

-- 查询时自动分区裁剪
SELECT * FROM orders 
WHERE order_date BETWEEN '2024-01-15' AND '2024-01-20';
-- 只扫描 p_2024_01 分区

嗯，这里要注意。我习惯在最后加一个 MAXVALUE 分区，防止数据超出预期范围时报错。这个习惯帮我避免过好几次线上事故。