优化Server中引用视图的策略？
更新:出于对您时间的尊重，我在子视图调用的表中添加索引。一旦我做了尽可能多的改进，我会回来编辑它，以尽量减少复杂性，并在我的帮助请求中更加具体。我也可以删除和重写这篇文章，如果这是首选。
瓶颈是子视图。估计的计划显示大部分工作是表和子视图之间的哈希匹配。链接查询计划
我理解谓词和联接列应该被索引。我不确定的是子视图的理想策略。
我是否应该：
- 将子视图转换为表值函数？我从一位专家那里听说，这是一个理想的解决方案，但他们没有说明原因。我不知道子视图中的索引列是否进入主视图
- 还是也需要将主视图转换为表函数以利用索引？
- 或者我离得太远了，根本不需要转换成表值函数？
主要观点：
SELECT *
FROM table1 WITH (INDEX(IX_table1))
INNER JOIN table2 WITH (INDEX(IX_table2)) ON table1.field1 = table2.field1
AND table1.field2 = table2.field2
LEFT JOIN SubView WITH (nolock) ON table1.field1 = SubView1.field1
AND table1.field2 = SubView1.field2
AND table2.field3 = SubView1.field3
AND table2.field4 = SubView1.field4
WHERE table1.PredicateDate >= dynamicDate
AND table1.field1 IN (3, 4)
AND table1.field5 = 0回答 2
Stack Overflow用户
发布于 2021-03-23 15:13:34
由于我无法控制的依赖关系，优化子视图需要一段时间。暂时无法删除这篇文章，所以结束了这个问题。
Stack Overflow用户
发布于 2021-03-22 15:40:54
抱歉。。。输入答案部分，而不是注释部分。但在尝试修复之后，这并不重要。。。没有足够的帖子来添加评论。
这是用于Microsoft系统中的表的。Microsoft的默认索引位于不应更改或删除的表上。在任何ERP升级中，索引都会被Microsoft重新创建。
大多数报告的表是顺序历史记录头(800万条记录)和行(5700万条记录)。当订单转到发票或发货时，这些表就会被填充。对于第一种情况，订单转到历史表，并在打开的表中创建发票。第二种情况，发票张贴时，一个声音被移到历史表上。对于这些流程，ERP系统有一个厚厚的客户端(自2010年或更早以来变化不大)。该过程是一个相当长的过程，包含许多不使用显式SQL事务的表。如果此过程被中断，则需要对任何未更新的表进行手动修复。
READONLY/READUNCOMMITTED最初用于针对活动数据库进行大规模报告。Vinh正在使用的视图用于当前已就位的复制服务器。READONLY通常是针对前几个月/几天中的信息使用的，因此当前的日期更改不是问题。大型报告减缓了上一段中讨论的转移和张贴程序。以上的投递过程目前需要大约1小时的时间来发布500项交易，所以我们可以随时保持这个过程不会减慢。
指定特定索引的原因:5700万行被划分为订单类型(SOPTYPE 2(订单)、3(发票)和5(后台订单))。大多数Microsoft索引使用SOPTYPE作为索引中的第一个字段。因此，大多数查询最终使用的是索引扫描而不是索引查找。在某些情况下，仅仅指定索引就可以将查询时间从2分钟缩短到5秒。当比较索引分数时，这两个指标可能都在80%，但SQL倾向于以SOPTYPE作为第一个索引字段来选择该索引。
我们可能是特定ERP系统的较大数据用户之一。我不相信微软已经为这个数据大小进行了优化。
我希望这些信息能有所帮助。
https://stackoverflow.com/questions/66726256
复制相似问题
腾讯云开发者
