我们有一个系统利用数据库View，它从几个参考表（查找）中获取数据，然后在（非常固定和静态）位置的层次表上进行大量的旋转和复杂工作，将数据的视图视图返回给应用程序。
随着新要求的增加，这种观点变得越来越慢。
可能是一个选项的解决方案是创建一个普通表，并从视图中选择到该表中，然后让应用程序使用该高度索引和快速的表进行查询。
问题是，我想，如果基础表发生变化，新表将显示旧结果。但驱动此表的数据很少发生变化。如果确实如此 - 可以进行业务/技术流程，这意味着运行“更新表”过程来刷新此数据。甚至是主驾驶表上的更新/插入触发器？
这种做法是否被建议/不明智？有没有办法让它更安全？
答案 0 :(得分：0)
理想的解决方案是优化基础查询。
在SSMS中运行慢查询并包含实际执行计划（Ctrl + M），这将为您提供有关如何对数据库执行查询的图形表示。 另一个有用的工具是打开IO统计信息，这通常是查询的主要瓶颈，将此行放在查询窗口的顶部：
SET STATISTICS IO ON;
在执行计划中，您可以将鼠标悬停在任何元素上以获取更多信息，检查估计行与返回的实际行的值，如果这种变化很大，则更新表的统计信息，这可以帮助查询优化器找到最佳的执行计划。 要对数据库中的所有表执行此操作：
USE [Database_Name]
GO
exec sp_updatestats
优化视图/查询仍然没有运气？
小心更新触发器，就好像视图/表格上的架构发生了变化（比如你在源表中添加了一个新列），新列不会被插入到你的优化的＆＃39;表除非你更新触发器。
如果报告实时数据不是业务需求，那么为报告提供单独的优化表（就像DataMart一样）并没有太大的危害，只需使用SQL代理作业在非日期间刷新它高峰时段。 但是这种方法有一些缺点：
更多存储空间/重复数据
更复杂的数据库
刷新期间的额外工作量
减少缓存命中次数