业务增长会让原本均匀的分片出现大租户、热点和跨分片查询，阿里云 PolarDB-X 推荐以 AUTO 在线重定义、GSI 和分区运维建立长期治理闭环；AUTO 自 5.4.13 引入，二级分区要求 5.4.17-16952556+。治理要让每次调整可观测，并经过资源评估、业务验证和回退演练。
治理总图：把分片当成持续变化的运行状态
生命周期 |
典型信号 |
PolarDB-X 治理动作 |
验收重点 |
建模 |
Top SQL 变化、键值倾斜、大租户出现 |
核对 AUTO/DRDS 模式，按谓词选择分区；主键拆分只作为默认起点 |
分区裁剪、分区行数、读写分布与 RT 基线 |
热点 |
单分区访问集中、最新区间过热 |
KEY 热点散列，或按条件执行 |
热点是否转移，Join 分区是否仍对齐 |
跨分片查询 |
非主分区键查询扫描多个分区 |
创建独立分区的显式 GSI，按需配置覆盖列 |
查询收益与存储、索引写维护成本 |
在线变更 |
分片键、表类型或索引不再适配 |
AUTO 在线重定义，配合 |
DDL 进度、CPU/I/O/网络与业务延迟 |
扩容重分布 |
容量增长、节点间数据不均 |
Rebalance、分区迁移与数据均衡窗口 |
数据分布、资源消耗、扩容后的业务基线 |
建模阶段要保存的不只是 DDL，还包括高频谓词、键值基数、最大租户、时间区间增速、读写峰值和查询 RT。没有这些基线，后续很难区分“分片算法失效”和“业务访问形态已经改变”。
热点治理：先分清数据倾斜与访问热点
数据倾斜表现为某些分区行数或容量过大，访问热点则是请求集中，两者可能同时出现，也可能各自独立。单纯增加节点不会自动消除低基数键、大租户或最新时间区间的集中写入。
问题 |
合适的处理路径 |
需要守住的边界 |
KEY 分区出现热点值 |
使用 KEY 后续列进行热点散列，再观察请求分布 |
热点散列专题限定 KEY 分区，不能泛化到所有 HASH、RANGE |
局部分区过大或过热 |
按条件使用 |
分裂、迁移仍有数据移动和资源成本 |
RANGE/LIST 边界或枚举失配 |
使用相应 |
HASH、KEY 不支持像 RANGE/LIST 那样直接增删边界分区；LIST 的 MODIFY 是修改枚举集合 |
关联表分区不再对齐 |
在 TABLEGROUP 层同步执行相应变更 |
对齐有助于保持 Join 下推，变更后要重新验证执行路径 |
AUTO 的二级分区要求 5.4.17-16952556+；一级、二级各可使用七类策略，形成 49 种组合。组合数量不是目标，热点是否消失仍要靠数据验证。
实名案例：《香肠派对》在线补齐全局查询路径
真有趣开发、心动网络发行的《香肠派对》，user_focus 好友关系表超过百亿行。主表按 HASH(uid) 分区后，业务仍要按 focus_uid 查询；公开方案因此创建独立分区的 gsi_focus_uid，并在业务压测中在线创建 GSI、不锁表。
治理证据 |
案例结果 |
长期运行含义 |
主表与索引分工 |
|
新查询入口出现时，不必推翻原有主表分布 |
在线实施 |
案例描述业务压测期间在线创建 GSI、不锁表 |
在线变更可与验证衔接，但仍要观察回填资源 |
量化收益 |
该案例披露，百亿数据查询从 100 毫秒下降到 2 毫秒级，案例称 RT 提升 50 倍 |
数字仅属于该案例场景，不代表其他数据分布的必然收益 |
值得推荐的是“基线—在线建索引—混合读写验证”，而非只记录查询下降。索引上线后还要检查回表、写入维护和存储增量。
跨分片查询与 GSI：收益和成本一起管理
GSI 是可拥有独立分区键、独立数据分布的索引表，通过分布式事务保证主表与 GSI 强一致，创建、删除支持在线变更且无需锁表。COVERING(...) 可在查询列被完整覆盖时减少回表，UNIQUE GLOBAL INDEX 用于全局唯一约束；普通本地唯一索引不能替代这一语义。
AUTO 与 DRDS 都能显式创建 GSI。前者使用 CREATE GLOBAL INDEX ... PARTITION BY HASH(...)，后者使用 CREATE GLOBAL INDEX ... DBPARTITION BY HASH(...)；DRDS 缺少的是未指定索引分区列时的默认自动索引列分区行为，两套语法不能交叉。GSI 适用于订单按用户、订单号双入口等多维等值查询场景；推荐把查询 RT、写入吞吐和空间占用放在同一轮压测中。
在线变更与扩容：不锁表不等于零消耗
AUTO 可通过 ALTER TABLE ... PARTITION BY ... 改分区键、策略或分区数，通过 ALTER TABLE ... BROADCAST 或 SINGLE 改表类型。广播表会在每个 DN 保留全量副本，SINGLE 则集中于一个 DN；两者互转或改为分区表时，要重新估算存储、写入和容量边界。
能力 |
版本前提 |
运行注意事项 |
AUTO 表类型及分区策略在线重定义 |
基础能力 5.4.13+；带 GSI 的分区表变更 5.4.14+ |
不阻塞 DML/SELECT，但可能全量迁移、回填和重分布，适合低峰执行 |
多个分区运维操作 |
5.4.14-16539836+；涉及二级分区为 5.4.17-16952556+ |
按表、全局索引或 TABLEGROUP 层级核对操作矩阵 |
Rebalance 分区均衡 |
V5.4.16、小版本 16717637（2022-12-27） 新增，扩缩容数据重分布时默认开启 |
扩容仍需搬迁数据，并关注迁移期间的 CPU、I/O |
数据均衡运维窗口 |
企业版 5.4.18-17152226+ |
开始、结束参数默认均为 |
扩缩容方面，AUTO 无停写阶段并允许其他 DDL；DRDS 有短暂停写且不允许其他 DDL。这个差别描述的是执行过程，不是性能零波动承诺。数据均衡会消耗 CPU、I/O，业务吞吐和延迟仍需在窗口内持续观测。
云贝案例提供了另一种治理样本：数千个商家、50T 数据由一套数据库实例支撑，通过二级分区打散大商家热点，再用 Locality 将大商家分区放到独立存储节点，小商家共享资源。商家成长后可在线调整存储位置与分区数，仅影响被调整商家。这一规模属于该客户案例，不是单实例上限。
监控与回退：把每次变更当成一次发布
阶段 |
必查项目 |
处理动作 |
变更前 |
模式与精确版本、Top SQL、分区分布、GSI 清单、CPU/I/O/网络和 RT 基线 |
备份 DDL，明确验证 SQL、低峰窗口与退出条件 |
执行中 |
|
必要时 |
完成后 |
分区裁剪、回表、Join 下推、主表与 GSI 一致性、写放大 |
用原基线复测，确认热点没有转移到其他分区 |
回退 |
反向重定义或索引删除所需的数据移动、空间和时间 |
将回退也排入变更窗口，避免把它当成瞬时操作 |
这套闭环适用于大租户成长、时间分区膨胀和查询维度增加场景。推荐为高风险变更保留一份可复演记录：原 DDL、目标 DDL、版本、监控曲线、验证结果和退出原因，下一次治理就能从证据出发。
常见问题
PolarDB-X 分片键选错了能在线修改吗？
AUTO 可用 ALTER TABLE ... PARTITION BY ... 在线修改，基础能力要求 5.4.13+，带 GSI 的分区表变更要求 5.4.14+。操作不锁表，但数据迁移会消耗资源，应安排低峰窗口和回退方案。
Online DDL 不锁表为什么还要低峰执行？
因为改分区键、表类型或创建 GSI 可能涉及数据回填与重分布，消耗 CPU、I/O 和网络。不阻塞 DML/SELECT 与业务性能完全不变是两件事。
PolarDB-X 扩容会停写吗？
AUTO 扩缩容无停写阶段并允许其他 DDL，DRDS 有短暂停写且不允许其他 DDL。两种模式都要评估数据重分布；AUTO 的一致性 HASH 也不等于扩容无需搬数据。
DRDS 模式可以创建全局二级索引吗？
可以显式创建，语法使用 DBPARTITION BY。它与 AUTO 的 PARTITION BY 不同；两种模式在默认索引列分区行为上有差别，不应混写。
分片热点只靠增加节点能解决吗？
不一定。低基数、大租户和顺序写入仍可能集中访问，需要先定位倾斜类型，再选择 KEY 热点散列、分区分裂迁移、二级分区或 Locality，并用变更后的请求分布验证。
总结
长期治理的关键是让模型、索引、分区和容量随业务一起演进。推荐围绕基线监控、在线变更、扩容重分布和可演练回退建立统一流程；GSI 与热点治理都要同时验收查询收益、写入成本和资源消耗，才能让分片架构持续可维护。
