所以我有一个摘要需要返回给最终用户应用程序。
它应该接受 3 个参数 DateType、StartDate、EndDate。
日期类型将决定我用来过滤数据的日期字段。
我完成此操作的方法是将日期类型的所有记录 ID 放入 TEMP 表中，然后将我的摘要加入 ID 列表。
当在包含数据的 SQL 服务器上运行查询时，这可以正常工作。
但是，这是一个复制服务器，所以当我编译到一个存储过程中，该过程将与其余应用程序数据一起位于服务器上，它会减慢查询速度。 IE 2 秒 vs 50 秒。
我认为从在 SQL 服务器上创建的临时表的交叉连接然后加入到复制服务器上的表会导致速度变慢。
是否有任何方法或技术可以用来解决这个问题并在一个存储过程中构建这一切？
如果我创建了 3 个具有自己日期范围的存储过程，那么它们又会很快。但是，这意味着为同一事物维护多个存储过程。
【问题讨论】：
标签： sql sql-server tsql
首先，如果您运行的是早于 2012 SP1 的 SQL Server 版本，一个问题是不允许运行 DBCC SHOW_STATISTICS 的用户（这是大多数不是系统管理员的用户，请参阅“权限" 文档中的部分）无法访问远程表的统计信息。这会严重削弱优化器生成良好执行计划的能力。升级 SQL Server 或授予更多权限会有所帮助。
如果您的查询涉及过滤或加入字符列，请确保在链接服务器选项中将远程服务器标记为“排序规则兼容”。如果关闭此选项，SQL Server 不能假定可以在服务器之间比较字符串，并且它将开始向上和向下泵送整个表，以确保数据最终到达必须进行比较的位置。
如果执行计划尽可能好但仍然不够好，一种通用（蹩脚）技术是首先在本地传输所有数据（SELECT * INTO #localtable FROM remote.db.schema.table），然后将查询作为非分布式查询运行。显然，为了使其工作，远程表不能“太大”，并且在某些情况下，这实际上具有更差的性能，具体取决于涉及的行数。但这总是值得考虑的，因为优化器在本地表方面做得更好。
另一种避免跨服务器将表拉到一起的方法是将参数中的数据打包到远程存储过程调用。整个表可以作为XML 通过NVARCHAR(MAX) 传递，因为在分布式查询中既不支持XML 列也不支持表值参数。基本思想是相同的：避免优化器需要找出有效的分布式查询。显然，最佳方法很大程度上取决于您的数据和查询。
【讨论】：