sql userid + name + profile优化问题

Question

我可能需要进行大量的userid-＆gt;用户名查找。所以我在想，而不是像下面的表那样

userid int PK
username text
userpass_salthash int
user_someopt1 int
user_sig text

让它分解如下

//table1
userid int PK
username text

//table2
userid int //fk
userpass_salthash int
user_someopt1 int
user_sig text

推理我会这样做是因为我怀疑一个不那么复杂的表（如果我愿意，我也可以使名称不再是32字节）更快的查找和更少的数据作为奖励。但我知道我可能是错的，我应该做哪个版本以及优化旁边的原因是什么？

Answer 1

您应该为规范化和性能执行第一个选项（单个表）。

性能：

• 如果您在(UserId, Username)上放置一个索引，那么您将拥有覆盖索引 - 因此您无需转到该表以获取用户名。
• 如果您将聚集索引放在UserId上，您将获得聚集索引搜索 - 无论如何都会以行数据结束。

归一化：

• 您的第二个选项允许用户存在于table1中，但不允许存在于table2中。由于您可能不希望没有密码的用户（无法登录），我认为这是破碎的。

我的建议是UserId的聚集索引。如果你需要聚集索引在其他地方，覆盖索引几乎一样好。

Answer 2

我同意，对于一张狭窄的桌子，一张桌子几乎肯定是最好的选择。

要添加的另一件事 - 文本数据类型（如果您使用的是MS SQL Server）非常广泛。 nvarchar（200）应该足够宽。自行使用LOB数据。

Answer 3

除非您确定需要，否则请不要担心优化查找。请记住Optmization Club的规则。

1. 优化俱乐部的第一条规则是，您不进行优化。
2. 优化俱乐部的第二条规则是，如果不进行测量，则不进行优化。
3. 如果您的应用运行速度比基础传输协议快，则优化已结束。
4. 一次一个因素。
5. 没有marketroids，没有marketroid时间表。
6. 只要必要，测试就会继续进行。
7. 如果这是您在优化俱乐部的第一个晚上，您必须编写测试用例。