SQL Server-非规范化联接表以提高性能

目前，我有一个巨大的用户表，我认为有几百万行，该用户表通过UserTypeJoin表链接到UserType表。搜索和筛选需要很长的时间，因为所有的连接都要连接到UserType表

我研究过使用索引视图，一开始看起来很棒，但当我尝试创建聚集索引时，我被告知聚集索引不能应用于具有左连接的视图。并不是所有的用户都有一个UserType，所以我需要做一个左连接

所以现在我认为去规范化是我最好的方法

我当前的表结构如下所示：

USER
UserId
UserName
Sex
Description

USER TYPE JOIN
UserId
UserTypeId

USER TYPE
UserTypeId
Name

我想把结构改成这样：

USER
UserId
UserName
IsUserTypeX bit
IsUserTypeY bit
IsUserTypeZ bit
etc...

用户可以有0到11个用户类型

我对数据运行的典型查询是使用用户的姓名、性别、描述、用户类型或这些属性的组合来搜索用户

这些表主要用于搜索，而不是用于写入，我最近做的所有研究都告诉我，读密集型表应该非规范化

在这种情况下，这是我最好的选择吗

---

或者有没有一种方法可以创建索引视图而不使用左连接，但仍然返回所有行？这无疑是一种更简单的方法，因为我不必更改大量代码。

在本例中，您可能希望做的一件事是再添加一个用户类型，我们称之为“非类型化”。在插入新用户时，将其设为默认类型。现在，您可以使用内部联接，而不会丢失任何行。这是一种更糟糕的数据管理，但在您的案例中，这种权衡可能是值得的

---

您正在检索所有行，然后进行筛选吗？在很多情况下，最好先过滤，然后加入。如果您将筛选条件与联接放在同一个查询中，查询优化器通常会使用此策略。

您考虑过使用存储过程吗？没有，但在这种情况下这对我有什么帮助？我仍然会让表联接减慢速度。为什么要返回没有用户类型的用户？可以，但是SQL server正在优化存储过程，并且正在存储它们的执行计划。此外，在执行计划分析中，您可以看到如何优化索引和其他内容。表结构更改IMHO是最后的手段。在整个集合上进行左连接需要多长时间？你预计需要多长时间？您是否尝试过只为了时间比较而进行内部联接？您知道执行查询使用的是什么计划吗？