为什么按位置读取 JDBC 结果集比按名称读取更快,读取速度快多少?

在宣布 Hibernate 6 时,Hibernate 团队声称,通过在 JDBC ResultSet 中从按名称读取切换到按位置读取,他们获得了性能优势。

高负载性能测试表明,Hibernate 按名称从 ResultSet 读取值的方法是其在通过 put 扩展时最大的限制因素。

这是否意味着他们正在将调用从getString(String columnLabel)更改为getString(int columnIndex)

为什么这更快?

就像接口一样,性能提升不依赖于实现它的 JDBC 驱动程序吗?ResultSet

收益有多大?


答案 1

作为 JDBC 驱动程序维护者(我承认,做了一些不一定适用于所有 JDBC 驱动程序的概括),行值通常存储在数组或列表中,因为这最自然地与从数据库服务器接收数据的方式相匹配。

因此,按索引检索值将是最简单的。它可能像这样简单(忽略实现JDBC驱动程序的一些令人讨厌的细节):

public Object getObject(int index) throws SQLException {
    checkValidRow();
    checkValidIndex(index);
    return currentRow[index - 1];
}

这几乎是它得到的速度。

另一方面,按列名查找需要更多的工作。需要将列名视为不区分大小写,无论使用小写还是大写进行规范化,还是使用 不区分大小写的查找,这都会产生额外的成本。TreeMap

一个简单的实现可能是这样的:

public Object getObject(String columnLabel) throws SQLException {
    return getObject(getIndexByLabel(columnLabel));
}

private int getIndexByLabel(String columnLabel) {
    Map<String, Integer> indexMap = createOrGetIndexMap();
    Integer columnIndex = indexMap.get(columnLabel.toLowerCase());
    if (columnIndex == null) {
        throw new SQLException("Column label " + columnLabel + " does not exist in the result set");
    }
    return columnIndex;
}

private Map<String, Integer> createOrGetIndexMap() throws SQLException {
    if (this.indexMap != null) {
        return this.indexMap;
    }
    ResultSetMetaData rsmd = getMetaData();
    Map<String, Integer> map = new HashMap<>(rsmd.getColumnCount());
    // reverse loop to ensure first occurrence of a column label is retained
    for (int idx = rsmd.getColumnCount(); idx > 0; idx--) {
        String label = rsmd.getColumnLabel(idx).toLowerCase();
        map.put(label, idx);
    }
    return this.indexMap = map;
}

根据数据库的 API 和可用的语句元数据,可能需要进行其他处理以确定查询的实际列标签。根据成本的不同,这可能仅在实际需要时才确定(按名称访问列标签时或检索结果集元数据时)。换句话说,成本可能相当高。createOrGetIndexMap()

但是,即使该成本可以忽略不计(例如,来自数据库服务器的语句准备元数据包括列标签),将列标签映射到索引然后按索引检索的开销显然高于按索引直接检索的开销。

驱动程序甚至可以每次只循环访问结果集元数据,并使用标签匹配的第一个;这可能比为具有少量列的结果集构建和访问哈希映射更便宜,但成本仍然高于按索引直接访问。

正如我所说,这是一个全面的概括,但如果这(按名称查找索引,然后按索引检索)不是它在大多数JDBC驱动程序中的工作方式,我会感到惊讶,这意味着我期望按索引查找通常会更快。

快速浏览一下许多驱动程序,情况如下:

  • 火鸟(Jaybird,披露:我维护这个驱动程序)
  • MySQL (MySQL Connector/J)
  • PostgreSQL
  • 神谕
  • HSQLDB
  • SQL Server (Microsoft JDBC Driver for SQL Server)

我不知道JDBC驱动程序,其中按列名检索的成本相当,甚至更便宜。


答案 2

在制作 jOOQ 的早期,我考虑了两种选择,即按索引或名称访问 JDBC 值。出于以下原因,我选择按索引访问内容:ResultSet

支持

并非所有 JDBC 驱动程序实际上都支持按名称访问列。我忘了哪些没有,如果它们仍然没有,因为我在13年内再也没有接触过JDBC API的那部分。但有些人没有,这对我来说已经是一个障碍。

名称的语义

此外,在那些支持列名的列名中,列名有不同的语义,主要是两个,JDBC称之为:

关于上述两个的实现有很多歧义,尽管我认为意图非常明确:

  • 列名应该产生列名,而不考虑别名,例如 如果投影表达式是TITLEBOOK.TITLE AS X
  • 列标签应该产生列的标签(或别名),如果没有可用的别名,则产生名称,例如 如果投影表达式是XBOOK.TITLE AS X

因此,名称/标签的这种模糊性已经非常令人困惑和担忧。一般来说,ORM似乎不应该依赖它,尽管在Hibernate的情况下,人们可以争辩说Hibernate控制着大多数SQL的生成,至少是为获取实体而生成的SQL。但是,如果用户编写 HQL 或本机 SQL 查询,我将不愿意依赖名称/标签 - 至少没有先在 中查找内容。ResultSetMetaData

歧义

在 SQL 中,在顶层使用不明确的列名是完全可以的,例如:

SELECT id, id, not_the_id AS id
FROM book

这是完全有效的 SQL。不能将此查询嵌套为不允许多义性的派生表,但在顶层可以。现在,您将如何处理顶层的这些重复标签?您无法确定在按名称访问事物时会得到哪一个。前两个可能相同,但第三个非常不同。SELECTID

明确区分列的唯一方法是按索引,这是唯一的:, , .123

性能

我当时也尝试过表演。我不再有基准测试结果,但很容易快速编写另一个基准测试。在下面的基准测试中,我在 H2 内存实例上运行一个简单的查询,并使用访问内容:ResultSet

  • 按索引
  • 按名称

结果是惊人的:

Benchmark                            Mode  Cnt        Score       Error  Units
JDBCResultSetBenchmark.indexAccess  thrpt    7  1130734.076 ±  9035.404  ops/s
JDBCResultSetBenchmark.nameAccess   thrpt    7   600540.553 ± 13217.954  ops/s

尽管基准测试在每次调用时运行整个查询,但按索引的访问速度几乎是其两倍!你可以看看H2的代码,它是开源的。它执行以下操作(版本 2.1.212):

private int getColumnIndex(String columnLabel) {
    checkClosed();
    if (columnLabel == null) {
        throw DbException.getInvalidValueException("columnLabel", null);
    }
    if (columnCount >= 3) {
        // use a hash table if more than 2 columns
        if (columnLabelMap == null) {
            HashMap<String, Integer> map = new HashMap<>();
            // [ ... ]

            columnLabelMap = map;
            if (preparedStatement != null) {
                preparedStatement.setCachedColumnLabelMap(columnLabelMap);
            }
        }
        Integer index = columnLabelMap.get(StringUtils.toUpperEnglish(columnLabel));
        if (index == null) {
            throw DbException.get(ErrorCode.COLUMN_NOT_FOUND_1, columnLabel);
        }
        return index + 1;
    }
    // [ ... ]

所以,有一个带有上层大小写的哈希图,每个查找也执行上层大小写。至少,它将映射缓存在预准备语句中,因此:

  • 您可以在每一行上重复使用它
  • 您可以在语句的多次执行中重用它(至少这就是我解释代码的方式)

因此,对于非常大的结果集,它可能不再那么重要,但对于较小的结果集,它肯定很重要。

针对 ORM 的结论

像Hibernate或jOOQ这样的ORM可以控制大量的SQL和结果集。它确切地知道哪个列在什么位置,在生成SQL查询时已经完成了这项工作。因此,当结果集从数据库服务器返回时,绝对没有理由进一步依赖列名。每个值都将位于预期位置。

在Hibernate中使用列名一定是一些历史性的事情。这可能也是为什么他们曾经生成这些不那么可读的列别名,以确保每个别名都是不明确的。

这似乎是一个明显的改进,无论在现实世界(非基准)查询中的实际收益如何。即使改进只有2%,它也是值得的,因为它会影响每个基于Hibernate的应用程序的每个查询执行。

下面的基准代码,用于复制

package org.jooq.test.benchmarks.local;

import java.io.*;
import java.sql.*;
import java.util.Properties;

import org.openjdk.jmh.annotations.*;
import org.openjdk.jmh.infra.*;

@Fork(value = 1)
@Warmup(iterations = 3, time = 3)
@Measurement(iterations = 7, time = 3)
public class JDBCResultSetBenchmark {

    @State(Scope.Benchmark)
    public static class BenchmarkState {

        Connection connection;

        @Setup(Level.Trial)
        public void setup() throws Exception {
            try (InputStream is = BenchmarkState.class.getResourceAsStream("/config.properties")) {
                Properties p = new Properties();
                p.load(is);
                connection = DriverManager.getConnection(
                    p.getProperty("db.url"),
                    p.getProperty("db.username"),
                    p.getProperty("db.password")
                );
            }
        }

        @TearDown(Level.Trial)
        public void teardown() throws Exception {
            connection.close();
        }
    }

    @FunctionalInterface
    interface ThrowingConsumer<T> {
        void accept(T t) throws SQLException;
    }

    private void run(BenchmarkState state, ThrowingConsumer<ResultSet> c) throws SQLException {
        try (Statement s = state.connection.createStatement();
            ResultSet rs = s.executeQuery("select c as c1, c as c2, c as c3, c as c4 from system_range(1, 10) as t(c);")) {
            c.accept(rs);
        }
    }

    @Benchmark
    public void indexAccess(Blackhole blackhole, BenchmarkState state) throws SQLException {
        run(state, rs -> {
            while (rs.next()) {
                blackhole.consume(rs.getInt(1));
                blackhole.consume(rs.getInt(2));
                blackhole.consume(rs.getInt(3));
                blackhole.consume(rs.getInt(4));
            }
        });
    }

    @Benchmark
    public void nameAccess(Blackhole blackhole, BenchmarkState state) throws SQLException {
        run(state, rs -> {
            while (rs.next()) {
                blackhole.consume(rs.getInt("C1"));
                blackhole.consume(rs.getInt("C2"));
                blackhole.consume(rs.getInt("C3"));
                blackhole.consume(rs.getInt("C4"));
            }
        });
    }
}

推荐