为简化情况，我将只考虑一张大桌子……
商店每晚会将一张大桌子的所有新数据和更改数据发送到总部。（这部分很好）此外，商店将过去 30 天该表的摘要发送到该大表的总部。
在总公司，新的和更改的数据在大表中更新（这里没问题）。收到并上传到表中的最后 30 个摘要。然后将它与一个查询进行比较，该查询汇总了同一商店的这个非常大的表（包含所有商店）的总部数据。< - 这就是问题所在。这样做是为了确保商店的数据与该商店的总部数据匹配（如果不匹配，我们会收到警告，他们需要采取行动）
问题是摘要查询花费了太多时间......我希望以更有效的方式改变我们将存储表与主机表进行比较的方式。
我尝试了索引视图，结果很好，但事实上它们有太多限制，由于结构不同，实际上不可能大规模实施（对所有软件所有者、收银机、商店和总部）以及我们软件的不同版本。
我一直在尝试不同的方法来确保商店的表格数据（至少过去 30 天）与总部相匹配，但我觉得我在转圈......所以我'正在寻找想法来帮助我以不同的方式看待这个问题。
限制：我们在商店使用 SQL Express，通常在总部使用标准。两个数据库之间没有直接连接（数据通过文件传输）。
任何帮助表示赞赏。谢谢你
添加了更多信息： 表的结构（我知道不理想，这是我继承的）： 日期、商店、终端、transNum、lineNum、数量、金额 + 194 更多列。 PK 和聚集索引为：Date, Store, terminal, transNum, lineNum
要总结的查询很简单：
Select Date, Store, sum(Qty) as Qty, sum(Amount) as Amt
from MyHugeTable
where date between '2017-07-22' and '2017-08-22'
and store = '1234'
group by Date, Store;
如果加快此查询的速度至关重要，我会考虑创建一个覆盖索引：
添加新索引将影响从表中添加、更新和删除行的时间。您应该测试以确定将此索引添加到每晚更新过程的影响。如果这加快了查询生成每天的摘要数据的速度，这将无济于事，但是插入和更新每日更改的速度比摘要查询速度更快。这适用于评论中的其他一些建议；测试以确保您所做的更改不会损害正常操作。
仅供参考：覆盖索引背后的想法很简单 - 如果索引具有查询引用的所有列，那么引擎可以从索引中检索该信息而无需实际接触表本身。该索引每行占用的空间应该比表（大约 200 列）少得多，因此查询应该执行得更好。
正如 David Browne 所指出的，您的索引不仅包括列出的四列，还包括构成主键的其他 3 个键。这是因为具有聚集索引的表上的所有非聚集索引都使用聚集键来标识主表中的行位置。有关完整详细信息，请参阅此链接。尽管如此，该索引仍将比您的~200 列表窄得多。
这是一个补充答案，我在这里做了一些假设，但看起来您正在尝试减少整体完成此过程所需的时间。在这种情况下，您不应该仅仅局限于弄清楚如何减少摘要查询。我并不是说您不应该优先考虑它，但您的流程中可能还有其他步骤可以节省额外的时间，从而最大限度地减少从摘要查询中挤出所需的性能。
如果您尚未这样做，我建议您将环境升级到SQL 2016 SP1 或更高版本。这打开了许多您可以使用的功能（即使是 Express 版本），这些功能可能有助于优化，例如Table Partitioning、Table Compression和/或Columnstore Indexing。这些功能可以单独使用，也可以相互结合使用，只要您当前没有遇到环境中的 CPU 瓶颈，就可以提供一些性能改进。
您还可以改进 ETL 导入流程。Microsoft 的这篇文章《优化批量导入指南》介绍了一些可能适用于您的方案的概念。里面有很多关于批量日志恢复模型的信息，如果你想使用它，我还会向你指出从完整或批量日志恢复模型切换的注意事项，其中介绍了在完整和批量记录恢复模型。
这里有很多东西，所以再一次，这并不是对您当前问题的回答，而是试图向您展示您可以在未来进一步改进的其他领域。