分区设计基础：分区概念与目的、分区粒度选择、分区键设计原则
好，咱们进入正题。分区设计这件事，说白了就是把一张大表拆成多张小表来管。你可能会问：表大了就大了呗，为什么要拆？我当年刚接触分布式系统时也这么想，直到有一次线上事故让我彻底改了观念。
分区到底解决了什么问题？
分区不是炫技，它解决的是实实在在的痛点。我归纳了三个核心目的：
- 提升查询性能——数据量大了，全表扫描就是灾难。分区后查询只扫相关分区，IO 量级直接降一个数量级。
- 增强可用性——一个分区挂了不影响其他分区。我记得有个项目，单表 2TB，重建索引要跑 6 小时。分区后每个分区重建只要 20 分钟，影响面小得多。
- 简化运维——删除旧数据直接 drop 分区，比 delete 快几百倍。你想想看，delete 要写 undo、redo，drop 分区只是元数据操作。
核心观点：分区不是银弹，但它是应对海量数据的第一道防线。不分区的系统，迟早要还债。
分区粒度：粗了没用，细了要命
分区粒度怎么选？我见过两种极端：有人把表按天分区，一年 365 个分区；有人干脆不分，硬扛。都不对。
粒度选择要看三个维度：
| 维度 | 粗粒度（月/季度） | 细粒度（天/小时） |
|---|---|---|
| 查询裁剪效率 | 差，可能扫多个分区 | 好，精准定位 |
| 分区管理成本 | 低，分区数少 | 高，分区数多 |
| 数据倾斜风险 | 低 | 高，热点分区明显 |
| 典型场景 | 归档、审计日志 | 实时流水、监控指标 |
我个人习惯是：先按业务访问模式定粒度。比如订单表，查询通常按月份查，那就按月分区。如果按天查是常态，再考虑按天。别为了「灵活」一上来就按小时分，那是给自己挖坑。
经验之谈：分区数控制在 50~200 之间比较舒服。太少没效果，太多管理成本飙升。我曾经接手过一个系统，分区数超过 1000，光列出分区就要等好几秒，DDL 操作更是噩梦。
分区键设计：选错了，分区等于没分
分区键是分区的灵魂。选对了，查询效率翻倍；选错了，分区形同虚设。我见过最典型的错误——用自增 ID 做分区键。为什么？因为新数据永远落在最后一个分区，前面的分区全是冷数据，查询还是扫全表。
分区键设计要遵循三条原则：
- 高选择性——分区键的值分布要均匀，避免数据倾斜。比如用用户 ID 的哈希值，而不是直接用用户 ID。
- 查询友好——分区键要出现在 WHERE 条件中。如果查询从来不按分区键过滤，那分区就失去了意义。
- 稳定性——分区键的值不要频繁变更。你想想看，一条记录的分区归属变了，意味着要跨分区移动数据，代价极高。
避坑指南：我曾经在项目中用时间戳做分区键，结果业务方要求按用户 ID 查历史订单。每次查询都要扫所有分区，性能比不分还差。后来加了用户 ID 的哈希作为二级分区，才解决问题。
常见分区策略对比
选策略时，我一般会画一张对比表，让团队一目了然：
| 策略 | 适用场景 | 优点 | 缺点 |
|---|---|---|---|
| 范围分区 | 时间序列、数值区间 | 管理简单，范围查询高效 | 数据可能倾斜 |
| 列表分区 | 地域、状态枚举 | 语义清晰，分区可控 | 扩展性差，新增值要加分区 |
| 哈希分区 | 高并发、均匀分布 | 数据分布均匀 | 范围查询无效 |
| 复合分区 | 复杂查询模式 | 兼顾多种查询 | 管理复杂，性能开销大 |
嗯，这里要注意：复合分区不是万能的。我见过有人把范围+哈希+列表三层嵌套，结果查询计划优化器都懵了，执行计划比全表扫描还慢。能用单层分区解决的问题，别上复合。
分区设计的核心逻辑
说了这么多，我画了一张图帮你理清思路。这张图展示了分区设计的决策流程：
这张图的逻辑很简单：先评估数据量，再决定要不要分。如果分，就分析查询模式，选合适的分区键和策略。最后别忘了持续监控——分区不是一劳永逸的事。
小结
分区设计没有标准答案，但有标准方法。记住三点：粒度要匹配业务、分区键要服务查询、策略要留有余地。我见过太多人把分区当成「加个字段」那么简单，结果上线后问题不断。嗯，分区设计值得你花时间认真推敲。