我有一个包含 30 列的视图，它们是从 6 个表连接起来的。该视图有 100 万条记录。当我从视图中搜索时，处理查询需要 5 秒。
我的问题是：
视图如何工作？它是在查询执行时加入，还是视图包含表等数据？ （有点像虚拟桌子。）
视图是否有任何限制，例如最大连接数或最大记录数？
如果我创建一个新表而不是视图，是否可以更快地检索记录？
【问题讨论】：
标签： sql sql-server
视图如何工作？它是在查询执行时加入，还是加入 视图包含表格之类的数据？ （有点像虚拟表。）
View 根本不包含任何数据，它只是一段类似于stored procedure 但“可加入”的已保存代码。
当您在查询中使用 view 时，将使用视图定义，视图名称将替换为视图定义，并为此查询构建 execution plan 并进行替换，您将不会在 @987654328 中看到任何视图提及@，仅基于表。
视图是否有任何限制，例如最大连接数，或者 最大记录数？
SELECT 语句的tables 的最大数量取决于您的server version，您可以在这里查看：Maximum Capacity Specifications for SQL Server，例如在2008 中等于256，在SQL Server 2017 中它是有限的仅取决于可用资源。
一个视图最多可以有 1,024 个columns，如此处所述CREATE VIEW (Transact-SQL)
返回的行数没有限制。
如果我创建一个新表而不是视图，我可以检索记录吗 更快？
这取决于。您应该检查execution plan 以进行查询。
请注意，如果您只是将查询返回的数据从视图定义复制到新表中，则当基于表中的数据发生更改时，它不会自动更新。
要使您的“数据副本”自动更新，您可以在视图上创建聚集索引。这称为Indexed view，有一些限制。
在任何情况下，您都应该从查询 actual execution plan 开始，以便找到服务器浪费时间的地方，并了解是基数估计错误还是基表上缺少 indexes。
【讨论】：
视图只不过是您可以将其视为表格的“已保存查询”
是的：视图可能会影响您的速度，在表中具体化您的视图可能会导致您获得更好的（读取）性能，因为您可以索引并避免“加入”开销。
我的建议是尝试这两种解决方案，分析它们，然后优化添加建议的索引。
物化的缺点是必须特别注意插入/更新（您必须更新后端然后重建/更新前端物化表）
PS： Damien_The_Unbeliever 建议使用索引视图：我告诉你它们存在，但我从未使用过它们，所以如果你选择使用它们，我将无法帮助你。
【讨论】：