业务增长会让原本均匀的分片出现大租户、热点和跨分片查询，阿里云 PolarDB-X 推荐以 AUTO 在线重定义、GSI 和分区运维建立长期治理闭环；AUTO 自 5.4.13 引入，二级分区要求 5.4.17-16952556+。治理要让每次调整可观测，并经过资源评估、业务验证和回退演练。
治理总图：把分片当成持续变化的运行状态
建模阶段要保存的不只是 DDL，还包括高频谓词、键值基数、最大租户、时间区间增速、读写峰值和查询 RT。没有这些基线，后续很难区分“分片算法失效”和“业务访问形态已经改变”。
热点治理：先分清数据倾斜与访问热点
数据倾斜表现为某些分区行数或容量过大，访问热点则是请求集中，两者可能同时出现，也可能各自独立。单纯增加节点不会自动消除低基数键、大租户或最新时间区间的集中写入。
AUTO 的二级分区要求 5.4.17-16952556+；一级、二级各可使用七类策略，形成 49 种组合。组合数量不是目标，热点是否消失仍要靠数据验证。
实名案例：《香肠派对》在线补齐全局查询路径
真有趣开发、心动网络发行的《香肠派对》，
user_focus 好友关系表超过百亿行。主表按
HASH(uid) 分区后，业务仍要按
focus_uid 查询；公开方案因此创建独立分区的
gsi_focus_uid，并在业务压测中在线创建 GSI、不锁表。
值得推荐的是“基线—在线建索引—混合读写验证”，而非只记录查询下降。索引上线后还要检查回表、写入维护和存储增量。
跨分片查询与 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 无停写阶段并允许其他 DDL；DRDS 有短暂停写且不允许其他 DDL。这个差别描述的是执行过程，不是性能零波动承诺。数据均衡会消耗 CPU、I/O，业务吞吐和延迟仍需在窗口内持续观测。
云贝案例提供了另一种治理样本：数千个商家、 50T 数据由一套数据库实例支撑，通过二级分区打散大商家热点，再用 Locality 将大商家分区放到独立存储节点，小商家共享资源。商家成长后可在线调整存储位置与分区数，仅影响被调整商家。这一规模属于该客户案例，不是单实例上限。
监控与回退：把每次变更当成一次发布
这套闭环 适用于大租户成长、时间分区膨胀和查询维度增加场景。推荐为高风险变更保留一份可复演记录：原 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 与热点治理都要同时验收查询收益、写入成本和资源消耗，才能让分片架构持续可维护。
