重复键、聚集索引和复合键

Question

嗨，我有一个系统，我将在一个组中拥有组/用户及其分数。作为示例，请检查这些列

GROUPID|USERID|SCORE|USERREGION

GROUPID

，

USERID

它们都是重复键（没有主键。）

假设我的数据库中有数百万用户。总共只有10个区域。

我想查询，

GROUPID

一个人

单独

USERID

或者

USERREGION

一个人 或

(GROUPID,USERID)

当用户想要查找他/她的某个组的分数时。

我将使用索引来增强性能，性能增强对我作为开发人员来说是最重要的概念。

由于我想要查询不同的键，因此拥有 1 个表并使其集群（排序）没有任何效果。即使我只有 1 个想要查询的键，我读到聚集表对查询性能没有任何增强，而是由 indexes 完成这项工作。

所以对于这种情况，拥有 3 个索引，

GROUPID

、

USERID

、

USERREGION

和 1 个复合索引

(GROUPID,USERID)

将足以实现最高性能？

考虑到我将拥有数百万用户，不需要创建多个表，对吧？

比如我有1000万用户，10个地区，平均每张桌子有100万用户。索引应该完成所有工作，而且我不需要对表上用户所在区域进行排序，对吗？

谢谢大家的意见。我知道这看起来像是基于意见的问题，但事实并非如此。我要求最好的增强方法，以及集群表在这种情况下是否有帮助，而不是提出意见。

谢谢你

Answer 1

GROUPID、USERID 它们都是重复键（没有主键。）

如果 (GROUPID,USERID) 对是唯一的，那么您可以拥有

PRIMARY KEY (GROUPID,USERID)

WHERE GROUPID = 123 AMD USERID = 2345

并且两列都有任何索引。 （请记住，

PRIMARY KEY

是一个“索引”。）

仅 GROUPID

WHERE GROUPID = 123

以及任何以 GROUPID 开头的索引

仅 USERID

WHERE USERID = 987

以及以 USERID 开头的任何索引

或单独的 USERREGION 或

WHERE USERREGION = 3

以及以 USERREGION 开头的任何索引

(GROUPID,USERID) 当用户想要查找他/她的分数时 组。

上面有？

聚集（排序）

“聚集”意味着数据按该键排序。 BTree 索引本质上是排序的，无论是否聚集。

没有效果

这要看情况。然而，只能有一个“聚集键”。另一方面，另请参阅“覆盖索引”。

集群表

INDEX，而不是TABLE，可以称为“集群”。

足以实现最高性能吗？

这取决于查询。让我们看看常见的查询。

考虑到我将拥有数百万用户，不需要创建多个表，对吧？

通常是这样。让我们看看常见的查询。

对表中的用户所在区域进行排序，正确吗？

由于根据定义，表是无序列表的行，因此这是无关紧要的。但是，该表上的聚集索引会强制对行进行排序。这对于某些查询是有利的。让我们看看常见的查询。