我有一个查询，它只从一张表和一个WHERE过滤器中进行选择。然而，它需要很长时间来执行，甚至偶尔会超时。这可能是因为它从 1300 万行（其他 900 万条记录早于 2019 年）的表中过滤掉了大约 400 万行，并且它返回了所有列，其中有 101 列（混合了datetime、varchar, 和int列）。它有两个索引，一个聚集在其主键上interaction_id的索引，和一个非聚集索引，interaction_date其上的日期时间列是主过滤器。这是查询：
SELECT *
FROM [Sales].[dbo].[Interaction]
WHERE
year(Interaction_date) >= 2019
通过添加/调整索引或调整查询本身，我可以做些什么来提高此查询的性能？在我进入 ETL 过程或反击需要此查询的组之前（他们是一个 Hadoop sqooping 团队，他们坚持认为他们需要一直使用所有列对所有这些记录进行 sqoop），我想看看我是否作为 DBA，我可以通过做一些事情来让人们更轻松。
默认情况下，查询计划会忽略我在interaction_date列上的非聚集索引，并且仍然执行完整的聚集索引扫描。所以我然后尝试通过包含WITH (INDEX(IX_Interaction_Interaction_Date))在选择中来强制它使用它。
这迫使它以非聚集索引的索引扫描开始进入查询计划，估计行数为 400 万，但估计行读取为所有 1300 万。然后在很短的时间之后，它会将剩余的执行时间花在主聚集索引的键查找上。
但最终，它似乎根本没有加快查询速度。
我正在研究一种解决方案，该解决方案将允许刷新报告表，从而可能让用户在需要刷新时读取它。有没有人实现了这样一种方法，而无需在刷新时终止用户与该表的连接？