📚 课程目录第4章分区键选择与数据分布评估

4. 分区键选择与数据分布评估

分区表能否真正解决大数据量下的性能问题，关键不在“分了几个区”，而在“按什么分”。分区键一旦选错，可能出现两类典型后果：一是数据严重倾斜，某个分区承载了 70% 以上的数据，查询仍然要扫描巨量行；二是热点写入，所有新增数据都落到同一个分区，形成写入瓶颈。因此本节的核心任务是：从时间、自增 ID、业务分类等候选键中筛选出最优方案，并评估数据倾斜、热点写入与查询模式，最终确定分区粒度。

一、候选分区键的优缺点对比

常见的候选分区键有三类，它们各自适配不同的数据特征与访问模式。

候选键	优点	缺点与风险	适用场景
时间列（如 OrderDate）	数据天然按时间递增，分区边界清晰；便于按时间范围裁剪（分区消除）；归档、清理历史数据简单	若业务集中在近期，最新分区可能成为热点；时间跨度大时分区数量增长快	日志、订单、流水、监控等时序型数据
自增 ID（如 OrderID）	分布均匀，几乎不会倾斜；分区数量可控	查询通常不按 ID 范围过滤，难以触发分区消除；新增数据全部写入最大 ID 所在分区，热点写入明显	仅按 ID 归档、极少范围查询的场景
业务分类（如 Region、TenantID）	与业务查询模式高度匹配，按分类过滤可直接裁剪分区	分类值分布往往不均，容易倾斜；分类数量变化时需要维护分区函数	多租户、按区域/渠道隔离的数据

从实践看，时间列通常是首选，因为它同时满足“数据可裁剪”和“可维护”两个条件。自增 ID 虽然分布均匀，但查询模式不匹配，分区消除几乎失效。业务分类适合作为组合分区键的第二列，而不是单独使用。

二、数据分布评估方法

选定候选键后，必须用真实数据评估分布，而不是凭感觉。评估分三步：

统计各候选值的行数与占比。例如按年、按月统计订单量，观察是否存在某个月份数据量远超其他月份。
计算倾斜度。常用指标是最大分区占比与平均分区占比的比值。若最大分区占比超过平均值的 2 倍，说明倾斜明显。
模拟查询裁剪效果。用典型查询的 WHERE 条件，判断能命中多少个分区，命中的分区是否仍然过大。

下面是一段评估时间列分布的示例查询，用于观察按月分布是否均匀：

SELECT
    YEAR(OrderDate)  AS OrderYear,
    MONTH(OrderDate) AS OrderMonth,
    COUNT(*)         AS RowCnt,
    CAST(COUNT(*) * 100.0 / SUM(COUNT(*)) OVER() AS DECIMAL(5,2)) AS Pct
FROM dbo.Orders
GROUP BY YEAR(OrderDate), MONTH(OrderDate)
ORDER BY OrderYear, OrderMonth;

假设示例结果中，2023 年 11 月占比 18%，而其他月份平均约 6%，则最大分区占比约为平均值的 3 倍，说明存在明显倾斜。此时若按月分区，11 月分区会成为查询和写入的双重热点。

三、热点写入的识别与缓解

热点写入的根源是“新增数据总是落在同一个分区”。时间列分区下，最新分区持续接收插入；自增 ID 分区下，最大 ID 分区持续接收插入。识别方法是观察插入语句实际写入的分区号，以及该分区的锁等待和页拆分情况。

缓解手段有三类：

细化粒度：把按月改为按周或按日，使最新分区更小，写入压力分散到更细的时间片。
组合分区：在时间列基础上叠加业务分类列，例如按“月 + 区域”分区，使同一时间片内的写入分散到多个分区。
预留空分区：提前创建未来分区，避免插入时触发分区切换或等待。

组合分区键的顺序很重要：范围列（时间）应放在第一列，分类列放在第二列。这样既能按时间裁剪，又能按分类进一步细分。

四、分区粒度的确定

粒度选择是“裁剪效果”与“管理成本”的平衡。粒度过粗，单分区仍然很大，裁剪收益低；粒度过细，分区数量膨胀，元数据管理和分区切换开销上升。

一个可操作的判断方法是：先估算单分区目标行数，再反推粒度。例如某表日均新增 200 万行，若希望单分区控制在 500 万行以内，则按日分区约 2.5 天一个分区，按周分区约 3500 万行偏大，按日分区更合适。若日均新增仅 20 万行，按月分区约 600 万行，按日分区则每区仅 20 万行，分区数量过多，此时按月更合理。

下图展示了从候选键评估到粒度确定的完整决策路径，以及时间、自增 ID、业务分类三类键在倾斜、热点写入和查询裁剪三个维度上的表现差异。

五、查询模式对分区键的反向约束

分区键不仅要看数据怎么来，还要看数据怎么查。如果绝大多数查询都带 WHERE OrderDate >= ... AND OrderDate < ...，时间列就是最优解；如果查询主要按 TenantID 过滤，则业务分类列更合适。若两类查询都频繁，可采用“时间 + 业务分类”的组合分区键，让两类条件都能参与裁剪。

需要特别注意的是，分区消除只对分区键列上的直接比较有效。若查询中对分区键使用了函数，例如 WHERE YEAR(OrderDate) = 2024，优化器往往无法裁剪分区，只能扫描全部分区。正确写法是使用范围条件：WHERE OrderDate >= '2024-01-01' AND OrderDate < '2025-01-01'。

不要为了“看起来均匀”而选择自增 ID 作为唯一分区键。均匀分布不等于高效查询，分区消除失效会让分区表退化为普通大表。

六、落地检查清单

在正式创建分区函数前，建议逐项确认：

候选键是否出现在主要查询的 WHERE 条件中，且能触发分区消除。
各候选值的行数占比是否已统计，最大分区占比是否超过平均值 2 倍。
新增数据是否集中落在单一分区，是否需要细化粒度或组合分区。
单分区目标行数是否明确，当前粒度下预估行数是否在可接受范围。
分区数量是否可控，是否预留了未来分区，归档与切换策略是否清晰。

综合来看，时间列在大多数时序型业务中应作为第一分区键，业务分类列可作为第二列用于进一步分散热点，自增 ID 通常只适合归档场景。粒度确定应以“单分区目标行数”为锚点，结合倾斜度与查询裁剪效果反复验证，而不是一次性拍定。