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