在 jOOQ 的 MULTISET 查询中，主表字段的选择往往被低估了。有人把注意力放在如何正确聚合子表集合上，却沿用单表查询的习惯，直接使用 asterisk() 投影整行。实际上，MULTISET 查询返回的每一行都同时包含主表列和一个嵌套的子表集合，主表列的宽度会直接决定结果集在网络传输和内存中的体积。尤其是当主表包含大文本或长备注字段时，多余的列会让查询效率明显下降。本文从主表字段选择、映射实践和性能优化三个层面，说明如何写出更轻盈、更可控的 MULTISET 查询。

主表字段选择为什么会被成倍放大

MULTISET 查询的核心思路是把子查询的结果作为一个嵌套集合打包进主表行。从最终返回的 Result 结构来看，一行主表记录会对应一个子表集合，这个集合可能包含 0 到 N 条子记录。主表字段虽然不会在每条子记录中重复，但它们会占据每一行的基础宽度。如果主表有 10 个字段，其中 5 个是列表页根本用不到的大字段，那么无论子表返回多少条数据，这 5 个多余字段都会出现在所有主表行里。

更值得注意的是，jOOQ 在部分方言中会用 JSON 或 XML 来模拟 MULTISET 结果。例如在 PostgreSQL 里，jOOQ 可能会生成 JSONB 聚合，将主表列和子表集合序列化成一个对象。此时主表字段越多，每个 JSON 对象的体积就越大，序列化和反序列化的成本也随之增加。即使不涉及 JSON 模拟，数据库驱动在读取结果集时也需要传输更多的字节。因此，主表字段并不是选得越多越省事，而是需要和业务界面或 DTO 精确对齐。

一个典型误区是直接写 AUTHOR.asterisk()，这样会把 BIO、AVATAR_URL、CREATED_AT 等无关列全部带出来。如果列表页只需要作者姓名和作品列表，这些额外字段既增加了 SQL 解析负担，也让映射后的对象携带了无用数据。后续如果主表增加新字段，使用 asterisk 的查询还会在不知不觉中把新字段也纳入结果集，可能引发意想不到的性能退化。

高效选择主表字段的三种方式

第一种方式是显式投影需要的列。jOOQ 的 select 方法完全可以逐个列出主表字段，这样查询意图清晰，也最容易被代码审查。以下示例中只选择了作者 ID、名字和姓氏，并同时聚合了书籍列表：

List<AuthorWithBooks> result = dsl
    .select(
        AUTHOR.ID,
        AUTHOR.FIRST_NAME,
        AUTHOR.LAST_NAME,
        multiset(
            select(BOOKS.ID, BOOKS.TITLE)
            .from(BOOKS)
            .where(BOOKS.AUTHOR_ID.eq(AUTHOR.ID))
        ).as("books").convertFrom(r -> r.into(BookSummary.class))
    )
    .from(AUTHOR)
    .fetchInto(AuthorWithBooks.class);

第二种方式是动态构造字段列表。当同一个方法需要根据请求参数返回不同范围的主表字段时，可以先收集 Field<?> 列表，再一次性传给 select。这样可以避免为每种字段组合写重复查询：

List<Field<?>> fields = new ArrayList<>();
fields.add(AUTHOR.ID);
fields.add(AUTHOR.FIRST_NAME);
if (includeLastName) {
    fields.add(AUTHOR.LAST_NAME);
}
fields.add(
    multiset(
        select(BOOKS.ID, BOOKS.TITLE)
        .from(BOOKS)
        .where(BOOKS.AUTHOR_ID.eq(AUTHOR.ID))
    ).as("books").convertFrom(r -> r.into(BookSummary.class))
);
List<AuthorWithBooks> authors = dsl
    .select(fields)
    .from(AUTHOR)
    .fetchInto(AuthorWithBooks.class);

第三种方式重点在于保留关联键。主表字段即使不在最终 DTO 中展示，只要它用于子查询的关联条件，就必须在 from 表里存在，并不一定要出现在 select 列表中。例如上面的子查询 where(BOOKS.AUTHOR_ID.eq(AUTHOR.ID)) 中，AUTHOR.ID 可以不出现在结果列里。但如果主表映射对象需要主键来做去重或更新，那么 ID 列还应该被选择。理解这一点可以进一步精简投影，避免选择那些既不展示也不参与后续逻辑的列。

主表字段与 Multiset 结果的映射实践

为了让查询结果顺利映射到 Java 对象，DTO 的字段名需要和 jOOQ 返回的列名保持一致。对于使用 Java record 的场景，可以先定义两个简单的 record，分别承载主表行和子表行：

public record AuthorWithBooks(
    Long id,
    String firstName,
    String lastName,
    List<BookSummary> books
) {}
public record BookSummary(
    Long id,
    String title
) {}

数据库列名通常是下划线风格，而 Java record 组件名使用驼峰。为了减少映射的不确定性，建议在 select 中通过 as 明确指定别名。例如 AUTHOR.FIRST_NAME.as("firstName") 和 AUTHOR.LAST_NAME.as("lastName")。这样 fetchInto(AuthorWithBooks.class) 会使用这些别名进行匹配，避免依赖全局设置或命名策略转换：

List<AuthorWithBooks> authors = dsl
    .select(
        AUTHOR.ID.as("id"),
        AUTHOR.FIRST_NAME.as("firstName"),
        AUTHOR.LAST_NAME.as("lastName"),
        multiset(
            select(BOOKS.ID.as("id"), BOOKS.TITLE.as("title"))
            .from(BOOKS)
            .where(BOOKS.AUTHOR_ID.eq(AUTHOR.ID))
        )
        .as("books")
        .convertFrom(r -> r.into(BookSummary.class))
    )
    .from(AUTHOR)
    .fetchInto(AuthorWithBooks.class);

映射时还要留意字段名冲突。假设主表本身也有一个名为 BOOKS 的列，而 MULTISET 结果也命名为 books，jOOQ 返回的结果集中可能出现重名列，映射时后出现的列可能覆盖前一个。因此最好为 MULTISET 列指定一个带有业务含义的别名，例如 bookList，并在 DTO 中使用相同的名字。对于嵌套 MULTISET，即子表里再聚合孙表，则需要为每一层都指定清晰的别名，否则 record 投影和转换会变得非常脆弱。

性能优化与常见误区

除了主表字段的精简，MULTISET 查询的性能还受到分页策略的影响。如果一次性加载大量主表记录，并且每条记录又嵌套了几十条子记录，内存峰值会迅速升高。此时可以结合 limit 控制返回行数，但对于深分页场景，offset 会让数据库扫描并丢弃大量数据。jOOQ 提供了 seek 方法用于 keyset 分页，可以在保持查询结构不变的情况下减少偏移扫描成本。

另一个常见误区是在拿到结果后手工遍历 record 做二次映射。例如先查询出 Result<Record>，再在循环里调用 record.get(...) 拼装 DTO。这种做法除了编写大量样板代码外，还容易绕过 jOOQ 的映射缓存。其实 fetchInto(Class) 和 convertFrom 已经能够处理大多数场景，应该优先使用。如果遇到复杂转换逻辑，可以实现 RecordMapper 并注册到配置中，让框架统一处理。

最后要注意方言差异对主表字段序列化的影响。在某些方言下，MULTISET 通过嵌套查询或 JSON 聚合实现，主表列会被序列化进中间格式。如果主表字段包含二进制数据或超大文本，序列化成本会非常突出。此时即使代码层面完全正确，查询也可能因为单个大字段而变慢。遇到这种情况，可以考虑把大字段从主表查询中移除，在真正需要查看详情时再单独加载，或者使用数据库的延迟列特性。

总体上，jOOQ 的 MULTISET 给一对多查询带来了很大的便利，但主表字段的取舍仍然是影响查询效率的关键。显式投影、别名字段、合理分页这三件事看似简单，却能显著降低结果集体积和映射成本。只要在编写查询时花一点时间审视主表列清单，就能避免很多不必要的性能损耗。