如何获取分页结果视图中的总结果数?

发布于 2024-08-12 23:34:10 字数 405 浏览 10 评论 0原文

我有一个数据库表,大约有。 100,000 个条目。

我的网络应用程序将显示搜索查询的分页结果,这可能会产生 0 到 100,000 条记录。

生成输出时,我想做两件事:

  • 显示结果总数
  • 显示分页视图,每页 50-100 个结果。

显然,我想一次只从数据库查询一页记录,但这里有一个困境 - 如何在不运行整个查询的情况下获取 COUNT() ?

如果我必须运行整个查询,那么选择全部查询并将其缓存在内存中不是更好吗?

在这种情况下,如果每个结果集有 100 k 条记录,您通常会做什么?

基本上, 能够显示“找到 xxxxx 结果”消息和拆分为页面的结果的最有效方法是什么?

I have a DB table with approx. 100,000 entries.

My web app will show paged results of search queries, which may yield between 0 and 100,000 records.

When generating the output I want to do two things:

  • Show total nr of results
  • Show paged view, with 50-100 results per page.

Obviously I would like to query records for just one page at a time from DB, but here is a dilemma - how do get the COUNT() without running the entire query?

And if I have to run the entire query, isn't it better to select it all and cache in memory?

What do you usually do in such a case, if we are in the range of 100 krecords per result set?

Basically,
What the most efficient way to be able to show both "found xxxxx results" message and results split into pages ?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

⒈起吃苦の倖褔 2024-08-19 23:34:10

显示总页数的成本很高。数据库必须完成您的查询直到最后一行。它必须从磁盘读取它们、执行联接、评估 where 子句和列计算。

所以它很贵,但是值得吗?事实证明,总页数是一个没有人使用的功能。因此,不要在这方面花费大量时间。这是不值得的。

不显示总页数。

It's expensive to show the total number of pages. The database has to finish your query up to the last row. It has to read them from disk, execute joins, evaluate where clauses and column calculations.

So it's expensive, but is it worth it? As it turns out, the total page count is a feature that nobody uses. So don't get side tracked into spending a lot of time on this. It's not worth it.

Don't show the total number of pages.

败给现实 2024-08-19 23:34:10

您可以通过运行单独的查询首先获取计数,而无需检索所有其他表列。

根据计数值,您可以决定检索/分页策略。

这里有很多与分页相关的帖子

You can get the count first by running a separate query, without retrieving all other table columns.

Depending on the count value, you can then decide your retrieval/paging strategy.

Quite a number of paging related posts in SO here.

a√萤火虫的光℡ 2024-08-19 23:34:10

这就是我之前沿着这些路线取得成就的方式。性能远非出色,但在使用它的特定上下文中,这并不重要(即使假设最坏的情况,也少于 70k 行,大多数查询都会过滤内部派生表到不存在问题的程度。

我会回显其他答案中表达的“这值得吗?”

DECLARE @StartRow INT
DECLARE @EndRow INT
SET @StartRow = 10;
SET @EndRow = 30;

SELECT M.[RowID], M.[UPRN], M.[Address_1], M.RowID+RowID2 as [TotalRows]
FROM
(
SELECT ROW_NUMBER() OVER (ORDER BY A1.UPRN ASC) as RowID,
       ROW_NUMBER() OVER (ORDER BY A1.UPRN DESC) as RowID2,
       A1.UPRN, 
       A1.Add_1
          FROM Core.Addresses A1
    ) as M
    WHERE M.RowID BETWEEN @StartRow and @EndRow

This is how I've achieved something along those lines before. Performance is far from great, but in the particular context it's used it doesn't matter that much (less than 70k rows even assuming worst case, most queries filter the internal derived table to the point where it's a non-issue.

I would echo the "is this worth it?" sentiment expressed in other answers.

DECLARE @StartRow INT
DECLARE @EndRow INT
SET @StartRow = 10;
SET @EndRow = 30;

SELECT M.[RowID], M.[UPRN], M.[Address_1], M.RowID+RowID2 as [TotalRows]
FROM
(
SELECT ROW_NUMBER() OVER (ORDER BY A1.UPRN ASC) as RowID,
       ROW_NUMBER() OVER (ORDER BY A1.UPRN DESC) as RowID2,
       A1.UPRN, 
       A1.Add_1
          FROM Core.Addresses A1
    ) as M
    WHERE M.RowID BETWEEN @StartRow and @EndRow
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文