[Bug] Console dataset list performs N+1 queries during response serialization

快速结论：这个报错通常出现在自托管 Dify 控制台打开数据集列表、或请求 GET /console/api/datasets?limit=30 时，单次响应序列化产生大量 SELECT 语句（每条约 9 条），本质是逐行字段级数据库查询导致的 N+1。优先排查 DatasetDetailResponseSource 的逐字段 get_* 调用链。

适用环境：Issue 已确认环境为 Dify 1.17.1，Self Hosted（Source）；问题发生位置为 Console API 数据集列表接口。Issue 未提及操作系统、Python、CUDA、显卡或具体依赖版本。

最快修复方案：暂无确认的一步修复方案。Issue 中未出现针对该 DatasetDetailResponseSource 逐行 fan-out 的已合并修复 PR，评论区只给出了可参考的批量加载改造思路（借鉴 #40125 的 prefetch 模式）。

注意事项：评论区提到的批处理方案属于改造建议而非已验证补丁，落地前需自行评估；相关改动不应改变响应字段与返回值。此外 has_more = len(datasets) == query.limit 未考虑服务端分页上限，属于同一 handler 内另一个独立问题，与本文 N+1 无关。

问题场景

用户在自托管 Dify 1.17.1（Source 部署）环境中，工作区内存在至少 20 个知识库数据集，随后打开控制台的数据集列表页，或直接请求 GET /console/api/datasets?limit=30。开启 SQL 查询日志、或在响应序列化期间统计 SELECT 语句数量时，可观察到查询数量随页面数据集数量线性增长；切换关键词过滤、刷新列表或翻页会重复执行同样的批量查询，导致响应延迟升高和数据库负载增大。

该接口被前端数据集页面实际使用，并非无人调用的闲置 API。

报错原文

[Bug] Console dataset list performs N+1 queries during response serialization

GET /console/api/datasets?limit=30

With 20 datasets, the measured response serialization performs 180 SELECT statements, or about 9 statements per dataset.

dataset_detail_response_source(dataset, session=session)

原因分析

根据 Issue 讨论，GET /console/api/datasets 会为每一行数据通过 dataset_detail_response_source(dataset, session=session) 构造 DatasetDetailResponseSource。该类在每个字段上分别调用 session 作用域的 getter，例如 get_app_count、get_document_count、get_word_count、get_author_name、get_tags、get_doc_form、get_external_knowledge_info、get_doc_metadata、get_is_published、get_total_documents、get_total_available_documents，而每个 getter 都会独立发起一次 SELECT。按每条数据集约 9-10 个此类字段计算，20 条数据集产生约 180 次查询，与实测数量一致。

因此这是响应序列化阶段的 N+1 查询问题，查询开销随页面数据集数量线性增长，而非某个数据损坏或配置错误。评论区指出同类放大模式在数据集 API 其他位置也出现过：文档列表接口 GET /datasets/{id}/documents 存在相同问题（#40123，修复见 PR #40125），索引状态接口的每文档重复统计问题已由 PR #42191 修复但明确不覆盖文档列表接口，本数据集列表接口同样不在其范围内；同接口早前另一个 partial_member_list N+1 已由 PR #32847 通过批处理修复，说明批 map 思路在该文件中已有先例。

环境排查

确认 Dify 版本是否为 1.17.1（Issue 已确认版本）。
确认部署方式：Self Hosted（Source），而非 Cloud。
确认工作区数据集数量是否达到 20 个或以上，以便复现线性增长。
确认是否启用了 SQL 查询日志，或能否在响应序列化期间统计 SELECT 语句数量。
确认请求的实际路径是否为 GET /console/api/datasets?limit=30，并尝试切换关键词过滤、刷新列表、翻页以观察查询数量变化。
Issue 未提及操作系统、Python、CUDA、PyTorch、显卡或数据库类型，无需补写这些项目。

解决步骤

先按上述环境排查确认问题可稳定复现：在自托管实例上准备至少 20 个数据集，开启 SQL 日志后请求 GET /console/api/datasets?limit=30，记录序列化阶段的 SELECT 数量。
定位代码位置：api/controllers/console/datasets/datasets.py 中 GET /console/api/datasets 处通过 dataset_detail_response_source(dataset, session=session) 逐行构造响应。
定位字段级查询来源：api/fields/dataset_fields.py 中 DatasetDetailResponseSource 的各个 get_* getter，以及 api/models/dataset.py 中它们各自执行的查询。
可优先尝试参考 PR #40125 的 DocumentResponsePrefetch 思路：在逐行循环之前，将页面上全部数据集 ID 的计数、标签、元数据和作者查询批量加载进字典（单次 IN 查询），再让 DatasetDetailResponseSource 从这些字典读取，而不是每个实例各调一次 get_*。
改造时保持响应字段和返回值不变，不要改变现有字段语义。
注意该方案为评论区给出的改造建议，截至 Issue 关闭并未有针对性 PR 合并，实施前需自行验证。
另注意同一 handler 中 has_more = len(datasets) == query.limit 未考虑服务端分页上限（#42024，PR #42030），与本 N+1 问题相互独立，若一并处理请分开验证。

验证方法

在修改后重新请求 GET /console/api/datasets?limit=30，开启 SQL 查询日志统计序列化阶段的 SELECT 语句数量。若问题解决，查询次数应不再随页面数据集数量线性增长（对照原实测：20 条数据集产生 180 次查询）。同时确认接口返回的字段和值与修改前一致，并对关键词过滤、列表刷新、翻页场景分别复核查询数量是否保持有界。