Closed wangyunlai615 closed 2 months ago
Question
我看官方文档中存在如下描述：
如果有一个电商 SaaS，【订单表】有 商户ID（ int ） 和 订单号（ varchar(32) ） 存在唯一约束，这个时候我们也应该用 这两个字段 做联合主键吗？
int
varchar(32)
众所周知，MySQL 采用的是 B+Tree 的结构来存储数据，一般建议 ID是自增的，这样可以避免随机插入，导致 MySQL 数据页频繁分裂，进而导致检索数据时 IO 开销增加。
然而，商户ID + 订单号 也很明显不是自增的，所以我才有此疑问。 对于这种场景，如果 OceanBase 仍然推荐使用它们联合作为主键，是因为 LSM-Tree 能够很好地处理 裂页 问题么 ？
此外，除了主键索引，我们一般还会额外在关键业务表上创建几个二级索引。 在 MySQL 中，因为每个二级索引的叶子节点都会存储相应行的主键值。所以，如果主键较大，那么每个二级索引的叶子节点所需的空间也会更大，因为它们需要存储更大的主键值。
如果主键是 bigint 的自增ID，在每个二级索引上存储，关联主键也就占用 8个字节 的空间。 如果主键是 int + varchar(32) 这种联合索引，是不是就意味着，关联主键也要占用至少 4+32 个字节的空间呢？ 如果有多个二级索引（一般2~4个），是不是也要重复多占用不少空间 ？这样的话，存储空间 以及 维护这些二级索引的开销不是也增大了许多么 ？
bigint
int + varchar(32)
4+32
Question
我看官方文档中存在如下描述：
如果有一个电商 SaaS，【订单表】有 商户ID（
int） 和 订单号（varchar(32)） 存在唯一约束，这个时候我们也应该用 这两个字段 做联合主键吗？众所周知，MySQL 采用的是 B+Tree 的结构来存储数据，一般建议 ID是自增的，这样可以避免随机插入，导致 MySQL 数据页频繁分裂，进而导致检索数据时 IO 开销增加。
然而，商户ID + 订单号 也很明显不是自增的，所以我才有此疑问。 对于这种场景，如果 OceanBase 仍然推荐使用它们联合作为主键，是因为 LSM-Tree 能够很好地处理 裂页 问题么 ？
此外，除了主键索引，我们一般还会额外在关键业务表上创建几个二级索引。 在 MySQL 中，因为每个二级索引的叶子节点都会存储相应行的主键值。所以，如果主键较大，那么每个二级索引的叶子节点所需的空间也会更大，因为它们需要存储更大的主键值。
如果主键是
bigint的自增ID，在每个二级索引上存储，关联主键也就占用 8个字节 的空间。 如果主键是int + varchar(32)这种联合索引，是不是就意味着，关联主键也要占用至少4+32个字节的空间呢？ 如果有多个二级索引（一般2~4个），是不是也要重复多占用不少空间 ？这样的话，存储空间 以及 维护这些二级索引的开销不是也增大了许多么 ？