什么时候应该使用sql视图

Question

我们有一个包含200万条PK用户ID记录的表，而不是唯一字段“公司”我们每小时有35,000个选择查询来检查我们的数据库中是否存在用户ID以及他与哪些公司相关。

我们应该在主表上运行大量查询，还是应该创建一个只包含userID和company字段的视图并对其运行查询？

有什么上行和下行？

我将非常感谢您的帮助！

P.S 每小时35,000个查询使用随机用户ID，并且每次都更改。 用户ID和公司没有更新，但我们每天增加大约20,000个新行。 我主要担心的是即使我对表格的其他字段进行更新，也会最小化选择的响应时间。

Answer 1

创建VIEW无济于事。每次使用它时，它都会简单地引用基础表。

在您查询的列上创建覆盖索引可能会有所帮助。假设您只需要UserID和Company：

 CREATE INDEX <Name> ON <Table> (UserID, Company)

现在，查询表格

SELECT Company FROM <Table> WHERE UserID = <Value>

可以从索引中满足

而不参考表数据。这可能会提高你的表现（在SELECT上）。

Answer 2

视图仍会查询主表，因此没有性能提升。它们主要用于

1. 仅对授权的行/列进行安全访问，
2. 如果需要复杂的连接，则简化客户端SQL。

在我们回答任何一个方向的利弊之前，我们需要知道您的顾虑是什么。

Answer 3

View只不过是queryable queries。我建议你应该创建一个只包含userID和company字段的视图，然后对它运行查询。但是，视图也会查询现有表。

要记住使用视图的一些points是：

1. 视图实际上只是存储的选择状态
2. 视图的数据是View引用的表的数据。
3. 在视图上创建索引将不适用于当前版本
4. 如果使用合并算法，则基础表的索引将为 使用。
5. 然而，基础指数不可见。描述视图 将不显示索引列。

希望这有帮助。

Answer 4

正如@dlgrasse所说，views对你没有帮助。

可以帮助您处理这些35000个查询的事情是已经将大量查询存储在查询缓存中。如果在同一时间内查询通常在同一用户上完成，则可能发生这种情况。获取在查询缓存上运行的查询的另一点是避免编辑（插入/更新/删除）来自此大表的行，在每次编辑后，来自查询缓存的所有查询都暗示此表将是无效。

因此，如果您在此表上有其他列需要一些工作，但您仍希望在user_id和公司字段上获得“快速查看”，这些字段不会移动很多，那么您可以创建一个专用表，仅包含那些领域，以及版本有限的地方。