我需要知道查询返回的总行以在网页中填充分页文本。 我在SQL方面进行分页以提高性能。 使用以下查询，我在15秒内获得6560个记录...

Question

1.

SELECT COUNT(*)
FROM dbo.vw_Lista_Pedidos_Backoffice_ix vlpo WITH (NOLOCK)
WHERE dataCriacaoPedido>=DATEADD(month,-6,getdate())

通过此查询，我在

1第二中得到了相同的结果：

2

SELECT COUNT(*) FROM
    (SELECT *, ROW_NUMBER() over (order by pedidoid desc) as RowNumber
    FROM dbo.vw_Lista_Pedidos_Backoffice_ix vlpo WITH (NOLOCK)
    WHERE   
        dataCriacaoPedido>=DATEADD(month,-6,getdate())
    ) records
WHERE RowNumber BETWEEN 1 AND 6560

如果我更改上述查询（2.），然后将rownumber的上限设置为大于6560的数字（计数（*）的结果），则查询再次需要

15秒

运行！

，我的问题是：

为什么查询2。花费的时间要少得多，即使对Rownumber的限制实际上并没有限制子查询中的任何行？

有什么办法可以使用查询2。在我的优势下获得总行？

这不会完全回答您的问题，因为真正的答案在于视图定义并优化了这一点。 这旨在回答有关行为的问题。

COUNT(*)
• 之所以慢的原因是因为它必须在视图中生成所有行，然后对它们进行计数。 计数不是问题。 这一代是
• ROW_NUMBER() over (order by pedidoid desc)
之所以快的原因是因为索引存在于

pedidoid

Answer 1

ROW_NUMBER()

。 而且，同样重要的是，它可以使用相同的索引访问视图中的数据。 因此，这加快了查询。

有6,561的魔术数字的原因。 好吧，我不知道。 这与SQL Server Optimizer的变化和您的配置有关。 一种可能性与

WHERE

子句有关：

WHERE dataCriacaoPedido >= DATEADD(month, -6, getdate())

我的猜测是，这种情况有6,560个匹配。  但是，SQL Server必须扫描整个表。  它扫描表格，找到匹配值。  但是，引擎不知道它已经完成，因此它一直在寻找行。  但是，正如我所说，这是解释行为的猜测。

真正修复了查询，您需要了解视图的工作原理。