PolarDB-X 最佳实践系列（四）：如何设计一张订单表
内容提要
介绍了使用全局索引与CO_HASH分区算法实现高效多维度查询的方法，提高了PolarDB-X等分布式数据库的查询效率。
延伸解读
从淘宝订单号看分布式设计巧思
文章通过观察淘宝订单号后四位长期一致的现象，揭示了分布式数据库设计中的实用技巧：将买家ID的片段隐藏在订单ID中，使得通过订单ID即可推导出买家ID，从而复用买家维度的分片。这种设计减少了额外索引或同步链路的需求，体现了业务系统生成字段时主动关联用户输入以降低系统复杂性的思路。
全局索引与聚簇索引的取舍
在PolarDB-X中，全局索引将索引数据按索引键分布到整个集群，解决了多维度查询的分片问题。但普通全局索引只包含索引键和主键，查询所有列时需回表，当订单数量大、分区多时回表代价可能接近全表扫描。聚簇全局索引通过冗余主表所有列来避免回表，以空间换时间，适合索引与主表一对多且查询频繁的场景。
CO_HASH的适用边界
CO_HASH分区算法允许将订单ID和买家ID的后几位关联，使两者落在同一分片，从而省略买家维度上的全局索引。其核心是让业务生成的ID携带用户输入的片段，实现维度降维。但文章也指出，CO_HASH只能减少存在关联的两个维度中的一个，若维度间完全无关，仍必须依赖全局索引，因此它并非万能方案。
Q&A
淘宝订单号后几位相同是什么原因？
这是分布式数据库的最佳实践之一。通过将买家ID隐藏在订单ID中，使得从订单ID可以推算出买家ID，从而在查询时能直接定位到买家维度的数据，避免全库扫描。
在分布式数据库中，如何解决买卖家订单查询问题？
可以使用两套订单表，分别以buyer_id和seller_id作为分库分表键，并通过binlog同步。但这种方法存在同步延迟、维护复杂等问题。更好的方案是利用全局索引或CO_HASH分区算法。
PolarDB-X中的全局索引和聚簇索引有什么区别？
全局索引只包含索引键和主键，查询时需要回表；聚簇索引（clustered index）包含表的所有列，可以避免回表操作，提高查询效率。
CO_HASH分区算法在PolarDB-X中有什么作用？
CO_HASH可以将两个关联的维度（如订单ID和买家ID）进行关联分区，使得通过其中一个维度能直接定位到数据，从而减少全局索引的数量，降低系统复杂性。
在PolarDB-X中如何创建全局索引来解决多维度查询？
可以使用CREATE CLUSTERED INDEX语句创建聚簇全局索引，例如：CREATE CLUSTERED INDEX gsi_buyer_id ON orders (buyer_id) PARTITION BY HASH(buyer_id); 这样无需修改SQL即可实现高效查询。
使用CO_HASH分区算法有什么限制？
CO_HASH只能减少两种存在关联的维度中的一维，如果两个维度完全不存在关联，则无法使用CO_HASH，必须使用全局索引。
