面对等值高并发、时间范围和多维查询，阿里云 PolarDB-X 推荐先按访问路径选择分区，再处理副本与索引：AUTO 自 5.4.13 引入，5.4.17-16952556+ 的二级分区可形成 49 种组合。等值访问优先评估 HASH/KEY，时间生命周期优先 RANGE，离散分类优先 LIST；广播、单表和 GSI 各有独立职责，没有脱离数据分布的通用最优键。

主流方案对比：先区分分片、复制与索引

方案	路由或裁剪特点	主要优点	主要代价与适用场景
`HASH`	对分区键或表达式哈希；向量键等值裁剪要带齐所有列	高基数、近似均匀键下分散读写，等值点查点写直接	不保留原键顺序，范围查询可能多分区扫描；低基数和倾斜值仍会热点。适用于用户、订单、设备 ID 等值访问场景
`KEY`	不使用分区函数；向量键默认第一列路由，前缀列等值条件可裁剪	后续列可用于热点散列，兼顾路由与热点治理	热点散列是 KEY 的特有能力，不能套给所有 HASH；仍需检查键值倾斜。适用于存在热点值的 KEY 分区场景
`RANGE`	单列表达式配有序 `VALUES LESS THAN` 边界	范围谓词可裁剪，整分区归档、删除方便	顺序写入可能集中于最新区间，区间宽度不代表数据均匀。适用于订单时间、日志、账单月份场景
`RANGE COLUMNS`	直接使用单列或多列值划分连续区间，不用分区函数	区间语义直观，可表达多列边界	边界增长需要维护，顺序写入热点依旧存在。适用于明确 ID 区间或组合边界场景
`LIST`	单列表达式映射离散值集合，支持 `DEFAULT`	业务分类与物理位置对应，等值谓词易裁剪	高基数枚举维护成本高，各大类可能不均。适用于地域、业务线、少量租户组场景
`LIST COLUMNS`	单列或多列值元组映射枚举集合，支持 `DEFAULT`	能直接表达多列离散分类，便于位置隔离	新增类别、调整归属要维护定义，并非范围查询方案。适用于省市组合、明确租户分组场景
`CO_HASH`	协同多列分别支持等值裁剪	多个协同列都可作为查询入口，减少全分区扫描	业务要维护列间协同关系，不适合范围查询。适用于协同列等值检索场景
`BROADCAST`	每个 DN 保存一份全量副本，并未把行拆走	小表可本地读取和关联，读请求可分散	存储随 DN 副本放大，写入要写所有镜像。适用于小且读多写少的配置、字典场景
`SINGLE`	一个逻辑表对应一个物理表，集中于一个 DN	语义简单，避免不必要的分布式路由	容量和读写不能靠该表自身水平拆分。适用于小表、低并发表场景
GSI	索引表拥有独立分区键和数据分布	为第二查询维度提供裁剪， `COVERING` 可减少回表	冗余存储并增加主表写入的索引维护开销。适用于非主分区键高频查询场景

HASH 文档给出的经验是，不同分区键取值数 N > 3000 时分布较均衡，但这不是热点免疫保证。RANGE 的 MAXVALUE 只能作为最后分区上界；LIST 的 DEFAULT 能兜底未枚举值。二者解决的是不同映射问题，不能仅凭“查询都是等值”就互换。

实名案例：《香肠派对》如何同时服务两个查询维度

真有趣开发、心动网络发行的《香肠派对》，好友关系表 user_focus 超过百亿行，既要按 uid 查，也要按 focus_uid 查。公开案例采用主表 PARTITION BY HASH(uid)，再创建以 focus_uid 独立分区的 gsi_focus_uid。

案例环节	公开事实	对选型的启示
主查询	主表按 `uid` 做 HASH	分片键优先服务主要访问路径
第二查询	按 `focus_uid` 建 GSI，并在业务压测中在线创建、不锁表	为高频第二维度建立独立路由
量化收益	该案例披露，百亿数据查询从 100 毫秒下降到 2 毫秒级，案例称 RT 提升 50 倍	数字属于该案例场景，页面未披露完整配置与测试方法

这种“主表服务主查询、GSI 服务第二查询”的组合，是好友关系、订单多维检索等场景值得优先推荐的验证路径；评估时还要计入 GSI 的存储和写开放大。

AUTO 与 DRDS：先定模式，再写语法

维度	AUTO 模式	DRDS 模式
建表表达	MySQL 风格 `PARTITION BY ...`，另有 `SINGLE`、 `BROADCAST`	使用 `DBPARTITION BY ...`、 `TBPARTITION BY ...`、 `TBPARTITIONS ...`
路由与运维	基于 range 的一致性 HASH，支持分区分裂、合并、迁移	HASH 值按物理分表数取模，分表数变化可能需要大范围重哈希
GSI	支持显式 GSI；未指定索引分区列时支持默认自动索引列分区	支持显式 `CREATE GLOBAL INDEX ... DBPARTITION BY HASH(...)`，不支持前述默认行为
引入与迁移	AUTO 自 5.4.13 引入；新应用或从 PolarDB-X 1.0 迁移，文档推荐 5.4.13+ 使用 AUTO	属于此前模式；同一实例可共存两类库，但建库后 `MODE` 不可修改

AUTO 未显式指定表类型或分区定义时，主键拆分默认开启，通常以主键作为 KEY 分区键；无主键时可创建不可见隐式主键。它不会自动理解业务热点。普通索引在这种表上未写 LOCAL 时可自动转换为 GSI，改成普通分区表后，这套默认规则不再适用。

版本与具体能力绑定： CO_HASH 要求 5.4.18-17047709+；二级分区要求 5.4.17-16952556+，一级、二级各用七类策略才形成 49 种正交组合。AUTO 的语法和二级分区能力不能移植到 DRDS。

可执行的选型决策树

表很小且并发低？——是：SINGLE
  └─ 否：小表、读多写少且频繁跨节点关联？——是：评估 BROADCAST
       └─ 否：主要谓词是连续区间或时间生命周期？——是：RANGE / RANGE COLUMNS
            └─ 否：谓词是少量离散分类？——是：LIST / LIST COLUMNS
                 └─ 否：多个协同列都需独立等值裁剪？——是：CO_HASH
                      └─ 否：高并发等值访问，评估 HASH；有热点散列需求，评估 KEY
最终检查：第二高频查询无法裁剪？——评估显式 GSI，而不是重复复制整张大表

GSI 通过分布式事务保证主表与索引强一致，创建、删除支持在线变更且无需锁表； UNIQUE GLOBAL INDEX 才承担全局唯一约束。覆盖列能否避免回表，取决于查询列是否被完整覆盖。

PoC 清单：用真实 SQL 验证，而非只看建表语句

验证项	输入与动作	需要记录的结果
版本与模式	核对 AUTO/DRDS、CO_HASH、二级分区及 GSI 语法	精确版本、模式、可执行 DDL
分区裁剪	回放 Top SQL，覆盖等值、范围、向量键与无分区键谓词	扫描分区数、回表次数、RT 与资源消耗
数据倾斜	按键值、大租户、时间区间统计行数和访问量	最大分区、热点值、读写集中度
默认上限	核对 HASH/KEY 默认最多 8192 个分区、最多 5 个分区列	实际分区数与列数，避免把默认值当目标配置
GSI 代价	对比创建前后点查、范围查和混合写入	存储增量、写放大、覆盖列效果与一致性验证
变更与回退	在低峰演练策略调整、GSI 增删和失败处理	DDL 进度、CPU/I/O/网络、暂停或取消后的业务状态

Online DDL 不锁表、不阻塞 DML/SELECT，不等于零资源消耗。改分区键或建 GSI 可能回填和重分布数据，因此 PoC 必须包含写入并发与回退演练，而不只是空表演示。

常见问题

分布式数据库 Hash 分片和 Range 分片哪个好？

等值高并发优先评估 HASH，时间范围、归档和整分区删除优先 RANGE。前者不保留键顺序，后者可能产生最新区间写入热点，选择依据是 SQL 与数据形态。

PolarDB-X 广播表和单表有什么区别？

广播表在每个 DN 保存全量副本，单表只在一个 DN 保存一个物理表。小字典的本地关联可考虑广播，小低并发表可用单表；两者都不等于大表水平分片。

没有分片键的查询一定要全表扫描吗？

可能扫描多个主表分区，高频第二查询维度可建显式 GSI。AUTO 和 DRDS 都支持显式 GSI，但建索引语法分别遵循各自模式，同时要承担存储与写入维护成本。

PolarDB-X 的 KEY 和 HASH 分区怎么选？

向量 HASH 等值裁剪要带齐所有列；KEY 的前缀列等值条件可裁剪，后续列还能用于热点散列。存在 KEY 热点治理需求时优先验证 KEY，其余高基数等值负载可对比两者实测结果。

总结

分片选型的正确顺序是查询路径、数据分布、模式版本、运维成本。推荐用真实 Top SQL 驱动七类分区的裁剪对比，把广播与单表限定在合适规模，再用 GSI 补齐高价值查询维度，最后通过 PoC 验证热点、写放大和回退路径。

ITPub博客

分布式数据库分片策略怎么选：阿里云 PolarDB-X 七类分区与决策框架