OceanBase数据库联合主键被其他索引引用，所占用的存储空间是不是也会变得更大？

在 OceanBase 数据库中，针对您提到的场景和问题，以下是详细的分析与建议：

1. 是否需要将商户ID和订单号作为联合主键？

在电商 SaaS 场景中，如果【订单表】的 商户ID 和 订单号 存在唯一约束，并且业务逻辑要求这两者组合起来唯一标识一条记录，那么从数据完整性和业务需求的角度来看，使用联合主键是合理的。
然而，是否一定要将它们设为主键，还需要结合以下因素进行权衡：

• 主键的作用：主键不仅是唯一性约束的实现方式，还决定了表的聚集索引结构（Clustered Index）。OceanBase 的主键设计会直接影响数据存储和查询性能。
• 非主键唯一约束的替代方案：如果您不希望将联合字段设为主键，可以通过创建一个单独的自增主键（如 BIGINT 类型），并在 商户ID 和 订单号 上创建唯一索引来满足唯一性约束。

因此，是否使用联合主键取决于业务对主键的依赖程度以及性能优化的需求。

2. 联合主键对聚集索引的影响

联合主键的设计确实会对聚集索引产生影响，尤其是在以下方面：

• 非连续自增的主键值：如果主键值不是连续递增的（如 商户ID + 订单号 的组合），会导致插入数据时频繁发生页分裂（Page Split），从而降低写入性能。这是因为 OceanBase 的聚集索引按照主键顺序存储数据，非连续递增的主键值会导致数据分布不均匀。
• 查询性能：对于范围查询或排序操作，联合主键可能不如单一递增主键高效，因为联合主键的排序规则更复杂。

因此，如果您的业务场景中写入操作频繁，或者对写入性能有较高要求，建议避免使用非连续递增的联合主键。

3. 联合主键对其他索引存储空间的影响

在 OceanBase 中，主键是所有二级索引的默认引用列（RowID）。如果主键是一个联合字段（如 商户ID + 订单号），则每个二级索引都会额外存储这两个字段的值，这会显著增加存储开销。具体影响如下：

• 存储空间占用：相比单一的 BIGINT 类型主键，联合主键的长度更大（INT + VARCHAR(32)），导致二级索引的存储空间成倍增长。
• 性能影响：更大的索引条目会增加 I/O 开销，降低查询性能，尤其是在涉及大量二级索引扫描的场景中。

4. 推荐的解决方案

基于上述分析，以下是针对您问题的推荐方案：

方案一：使用单一自增主键

• 设计思路：为表添加一个单独的自增主键（如 BIGINT 类型），并在 商户ID 和 订单号 上创建唯一索引。
• 优点：
  • 主键连续递增，减少页分裂，提升写入性能。
  • 减少二级索引的存储开销，提高查询效率。
• 示例 SQL：

  CREATE TABLE orders (
    id BIGINT AUTO_INCREMENT PRIMARY KEY, -- 自增主键
    merchant_id INT NOT NULL,             -- 商户ID
    order_no VARCHAR(32) NOT NULL,        -- 订单号
    UNIQUE (merchant_id, order_no)        -- 唯一约束
  );
  

方案二：使用联合主键

• 设计思路：直接将 商户ID 和 订单号 设为联合主键。
• 适用场景：如果业务逻辑强依赖于联合主键（如分布式事务或分片键设计），可以选择此方案。
• 缺点：
  • 写入性能可能下降，尤其是高并发场景。
  • 二级索引存储开销较大。
• 示例 SQL：

  CREATE TABLE orders (
    merchant_id INT NOT NULL,             -- 商户ID
    order_no VARCHAR(32) NOT NULL,        -- 订单号
    PRIMARY KEY (merchant_id, order_no)   -- 联合主键
  );
  

5. 总结建议

• 如果您的业务对写入性能和存储效率有较高要求，推荐使用单一自增主键，并通过唯一索引保证 商户ID 和 订单号 的唯一性。
• 如果业务逻辑强依赖联合主键（如分布式架构下的分片键设计），可以考虑使用联合主键，但需注意其对性能和存储的影响。

通过合理选择主键设计，可以在满足业务需求的同时，优化数据库性能和存储成本。