在 JPA 中获取表大小是一项昂贵的操作吗？答案

【问题标题】：Is getting the table size in JPA an expensive operation?在 JPA 中获取表大小是一项昂贵的操作吗？
【发布时间】：2017-09-26 17:56:45
【问题描述】：

我在我的 Web 应用程序中实现了用于表格查看的服务器端分页。这意味着用户有按钮来激活第一页、最后一页、下一页和上一页。每次点击都会产生一个服务器请求，其中只返回要显示的记录。

要实现“最后一页”功能和滚动条，我需要客户端具有表格的大小。我可以通过以下方法在服务器端获取它：

public long getCount(Class entityClass) {
    CriteriaBuilder builder = em.getCriteriaBuilder();
    CriteriaQuery<Long> query = builder.createQuery(Long.class);
    Root root = query.from(entityClass);
    Expression<Long> count = builder.count(root);
    query.select(count);
    TypedQuery<Long> typedQuery = em.createQuery(query);
    return typedQuery.getSingleResult();
}

这个表可能非常活跃，有数百万条记录。运行此函数是否会导致 SQL 服务器中的大量 CPU 周期被使用？

问题在于此应用程序的扩展性如何。

【问题讨论】：

我们目前正在自己处理这个问题，我想说的是，您可能只需要执行一次计数查询，而无需在后续页面上执行。如果是这样，那么COUNT 查询的成本可能不是影响分页搜索性能的最大因素。

标签： mysql sql jpa jpa-2.0

【解决方案1】：

这完全取决于数据库，我知道的所有 JPA 实现都会将 count 转换为 select count(*) from Table。我们有一个带有 130GB 数据的单个表的 Postgresql，大多数行只有几千字节。做select (*) from table 需要几分钟；一位开发者曾经做过一个简单的未索引的选择查询，一次全表扫描大约需要 45 分钟。

在进行分页时，您通常会有一个过滤器，重要的是对数据查询和计数查询应用相同的过滤器（使用 CriteriaBuilder 的主要原因之一是共享过滤部分询问）。今天我推荐使用Spring-data，因为它使分页几乎毫不费力。

如果你有很多数据，你可以像 google 一样，说 'zip' 有 1.340.000.000 个结果，但只允许你向前跳转 10 页，如果你运行到最后你会看到他们实际上只加载了 1000 页。换句话说，它们会缓存估计大小，但需要您缩小搜索范围以提供更精确的结果。

【讨论】：