SQL Server 2012 分页和 TotalRows答案

【问题标题】：SQL Server 2012 Paging and TotalRowsSQL Server 2012 分页和 TotalRows
【发布时间】：2014-06-03 18:15:02
【问题描述】：

我刚开始在 SQL Server 2012 中进行分页，我试图在应用分页之前获取总行数，但我遇到的问题是我的视图中有太多的函数调用大大减慢速度。

我查看了这篇博文，结果发现在数据库中没有完整数据集的情况下运行需要 39 秒的查询。

    SELECT *
    , COUNT(TaskId) OVER()
FROM TaskVersionView
WHERE (.. ~10 predicates here .. )
ORDER BY StartDate
OFFSET 0 ROWS
FETCH NEXT 50 ROWS ONLY

如果没有 COUNT，则需要

我原以为 SQL 会对其进行优化，使其仅计算 TaskId 而不是调用函数，但似乎并非如此，因为：

SELECT COUNT(TaskId)
FROM TaskVersionView

耗时

【问题讨论】：

标签： sql sql-server pagination sql-server-2012

【解决方案1】：

我本来希望 SQL 对其进行优化，以便它只计算 TaskId 而不是调用函数

如果谓词始终为“真”，则此“优化”将返回正确的值。即使在理论上，SQL Server 也不能猜测函数将始终返回 true。但是，如果您知道（这似乎暗示了您的期望）谓词中的函数总是返回 true，那么显然您应该将它们从 WHERE 子句中删除...
如果谓词有时返回“false”，那么显然它们不能被优化掉，因为返回的值是不正确的。

必须付出一些。

附言。使用总计数进行分页是个坏主意，因为它会强制每次访问都进行全面扫描。 为每一行返回总计数的总计数分页是一个可怕的坏主意（明智的建模，明智的性能，明智的理智）。

【讨论】：

只是为了澄清我的谓词中没有函数。这是我正在建模的层次结构（具有嵌套子任务的任务），因此这些函数用于上下遍历树以下拉数据以显示在视图中，这在较大的数据集上很慢。我对像这样完成的总计数感到担忧，但有没有合理的替代方案？
我会说问题出在 UX/UI 中。 为什么显示总数？今天有很多选择，例如。具有强大过滤功能的连续滚动。阅读The End of Pagination。如果您坚持分页，那么一旦您达到任何合理的数据大小和流量，总计数将总是难以破解。我已经看到在解决这个问题上投入了数千小时（例如，通过应用缓存 + 内存中计数维护）。
我同意无休止的滚动。但问题是在某些情况下，我可能会在屏幕上显示 5 个以上的表格作为仪表板，因此需要分页和总计数。跨度>
选择你的毒药：近似：显示接近准确但计算成本低的计数。缓存：显示过时的计数并每分钟左右刷新一次。 预计算：使用indexed views 预计算聚合（对更新有严重的锁定后果）。整个 9 码是内存中的缓存计数，由应用程序不断更新。在单个节点上很难实现，在应用程序场上几乎是不可能的。