主题综述 · database（2026-07-22）

  • 作者：spark
  • 更新：2026-07-22

本文综合 KB 内 paper_cards/ 收录的相关工作 8 篇 + inbox/jay/2026-07-21-database-e1prep.md（174 行）+ inbox/jay/2026-07-22-database-e1prep.md（214 行）+ organized/knowledge/database.md 活文档 R-15–R-17（400 行，138 个 arXiv ID + 2 CVE）+ inbox/jay/2026-07-22-1105/1505-database-backend-cloudnative-csdn(-repro).md 两份跨域简报 + 一条 2026-07-22 web 信号（SIGMOD 2026 印度班加罗尔 Research-8: LLM and Vector Retrieval 完整议程），对 2026 年中后期 "Database 作为 LLM / Agent 数据层" 这一主题做深度盘点。所有观点均附引用出处（arXiv 编号或 inbox / 活文档路径），不复用未核验的数字；待核验条目集中标注在 §5.3。

一、主题脉络：从 "存储引擎" 走到 "LLM / Agent 数据层"

organized/knowledge/database.md 第 R-17 段已经把数据库赛道在 2026 Q3 切成七块：(i) 关系型引擎吞并向量 + 图能力；(ii) 专用向量库被推到超大规模 + 特定过滤场景；(iii) HTAP "统一"概念失败 + 云原生数据栈成熟；(iv) AI4DB / Text-to-SQL 进入"数据质量 > 模型架构"阶段；(v) 数据库与 Agent 记忆边界融合 + 反方证据主导；(vi) Agent-First DB 三路径并行；(vii) 跨引擎 KV cache 2026 H1 = "系统服务"。这条切法与 2026-07-22 jay E1 预消化（inbox/jay/2026-07-22-database-e1prep.md）的 7 条核心增量（QVCache / Filtered ANN / VeloANN / GPU Vector Search / Aurora DSQL / Jailbreak / Cross-Encoder Reranking）高度吻合——本轮 pre-digest 把焦点收口到「向量 DB 工程化评测簇 + 分布式 OLTP 新架构 + LLM×DB 安全」三股力，与活文档七块框架互补而不冲突。

把时间轴往回拉一格，2026 年中后期数据库主题的演化路径可以压缩成四跳：

跳 主导问题 关键载体 标志性产物
2024 H2 — 2025 H1 "如何把 embedding 索引好" HNSW / IVFFlat / ScaNN Qdrant / Milvus / Pinecone 独立赛道成型
2025 H2 — 2026 H1 "如何把向量库搬进关系型引擎" pgvector 0.8 + pgvectorscale / SQL/PGQ pgvector+pgvectorscale 50M 471 QPS（Salt 2026 Q1）；PG 19 GA 2026-09（postgresql.org/developer/roadmap）
2026 H1 "如何把 KV cache 当存储引擎调度" LMCache / Mooncake / vLLM × Mooncake Store / RetroInfer / HNSW-Merger KV Cache Optimization 综述（arXiv 2603.20397）五方向叠加 LCA（arXiv 2604.12452v2 ACL 2026 Long Paper）
2026 H2 至今 "如何让数据库成为 LLM / Agent 的执行基座 + 数据层一体化" QVCache / VeloANN / Filtered ANN Benchmark / Aurora DSQL / Jailbreak / PA-HDP / GenDB / Cortex AISQL 数据库顶会 SIGMOD 2026（班加罗尔 6-22~26）Research-8 "LLM and Vector Retrieval" 单设 session，含 DepCache / KVDrive 两篇 KV cache × GraphRAG 工作；SIGMOD 2026 同期接收 HNSW-Merger（Purdue Jianguo Wang Lab）；VLDB 2026 接收 RetroInfer（MSRA）、Q-Doctor（华中科技大学 × 阿里）、BOND（VLDB 2026）

这一轨迹对应着一个判断：2026 年的 "database" 主题不再只是 "向量库 + 关系型引擎"，而是被 LLM / Agent 的负载形态倒逼重写的「数据层操作系统」——既要承担 RAG / Agent 检索的事实层（vector / BM25 / graph hybrid），也要承担 Agent 状态的存储层（记忆系统 + KV cache 持久化 + multi-tier tiering），还要承担 LLM×DB 的双向融合（AI4DB / Text-to-SQL + LLM-as-Query-Engine + DB-as-LLM-Memory）。今天的综述围绕这条主线，按八个切片（向量缓存 / 索引评测 / DiskANN / GPU 混合 / 分布式 OLTP / LLM×DB 安全 / RAG 数据层 / 跨引擎 KV cache 边界）展开。

二、各工作贡献与相互关系

下面把 8 篇核心 KB 内/外可定位到 database 主线的工作（覆盖向量缓存层 / ANN 横向评测 / SSD 图索引 / GPU 关系引擎 / 分布式 OLTP / LLM×DB 安全 / RAG 外部库隐私 / RAG reranking 工程化）+ 2 个顶会信号（SIGMOD 2026 Research-8 + VLDB 2026）+ 1 个活文档锚点（PG 19 + pgvector + HNSW-Merger）串起来。

2.1 向量缓存层：QVCache 把"查询局部性"做成生产级工程

arXiv 2602.02057 · QVCache: Query-Level Vector Caching（论文 arXiv 链接：https://arxiv.org/abs/2602.02057，KB paper_cards/ 暂无单独卡片；来源 inbox/jay/2026-07-22-database-e1prep.md 增量 1）

billion-scale 向量搜索长期面对"内存容量 + I/O 带宽"双重瓶颈——全内存成本高，磁盘方案在高召回下尾延迟骤降。QVCache 第一次把查询级缓存层作为独立系统提出，可以无侵入地部署在现有 ANN 系统之上。三个关键设计：

  • 在线学习算法动态学习区域级距离阈值，对缓存命中提供有界召回率保证（bounded recall guarantee）——这是该工作最具学术分量的创新：它把工程意义上的"缓存"提升到了"召回率可证明不会显著下降"的理论级声明。
  • 内存占用 MB 级（megabyte-scale），与数据集规模解耦。
  • 命中延迟 <1 ms。
  • 端到端：在现有 ANN 系统之上叠加 QVCache 后，尾延迟降低 40–1000×。

与活文档锚点（organized/knowledge/database.md §2.1）的"过滤性能比向量召回率更容易拖垮生产"工程警示形成精确对应——QVCache 是对该问题的系统性工程回应。Bounded recall guarantee 是生产可用性的关键保障；它解决了向量缓存"敢不敢用"的根本问题。与 vLLM prefix caching 思路互补但专门针对向量搜索场景：vLLM 缓存的是 prompt token prefix，QVCache 缓存的是 ANN 内部查询轨迹；二者属于同一类"查询局部性工程化"哲学的不同物理载体。RAG 场景下，QVCache 对"重复 RAG 查询 + 时空局部性明显的工作负载"具有直接落地价值（§2.8 RAG 小节预留归入位置）。

2.2 ANN 横向评测：Filtered ANN Benchmark + GLS 指标

arXiv 2602.11443 · Filtered ANN Benchmark（Milvus / pgvector / FAISS）（来源 inbox/jay/2026-07-22-database-e1prep.md 增量 2 + 活文档 §2.1 R-17 fresh）

现有 FANNS（Filtered Approximate Nearest Neighbor Search）研究缺乏对主流向量数据库实际性能差异的系统理解。本工作做出三个贡献：

  1. 过滤策略分类学（Taxonomy）：系统化梳理 filtering strategies 与 ANN 索引的组合方式。
  2. 跨系统实测：在 FAISS、Milvus、pgvector 上对比集成效果，引入新数据集 MoReVec（768 维文本嵌入 + 丰富元数据属性）。
  3. GLS（Global-Local Selectivity）指标：量化"过滤器与查询向量相关性"。

关键发现（活文档与本工作都反复确认）：

  • Milvus：召回率稳定性最优；其混合近似/精确执行机制表现突出。
  • pgvector：成本优化器频繁选错执行计划——在精确扫描能达到完美召回且延迟相当的情况下，仍偏好近似索引扫描。这是 R-17 段就标注过的"⚠️ 待核实"警示，本工作的独立实验进一步放大其可信度。
  • IVFFlat > HNSW：对低选择性（low-selectivity）查询，分区索引表现优于图索引。

工程含义直接指向活文档 §2.1 决策树：< 10M + 已有 PG → pgvector 默认 / < 50M + 已有 PG → pgvector+pgvectorscale / < 100M + 自托管 → Qdrant / > 数亿 → Milvus / 零运维 → Pinecone Serverless / 边缘 → LanceDB。GLS 指标是原创贡献，值得作为活文档 §2.1 的专项备注。⚠️ 待核实：pgvector 成本优化器执行计划异常目前仍为单一论文独立发现，建议后续轮次补一次第三方复现。

2.3 DiskANN 路线新成员：VeloANN 拿到"10% 内存 = 92% 吞吐"

arXiv 2602.22805 · VeloANN: SSD-Locality Graph ANN Index（来源 inbox/jay/2026-07-22-database-e1prep.md 增量 3）

HNSW 等图索引在磁盘环境下遭受严重存储停顿（storage stalls）。VeloANN 通过三个设计解决：

  1. 局部性感知数据布局（locality-aware data layout）：减少随机 I/O。
  2. 协程异步运行时（coroutine-based async runtime）：掩盖 I/O 延迟。
  3. 记录级缓冲池（record-level buffer pool）：每个记录 = 一个向量的全部邻居；热记录常驻内存，消除过量页交换。

实验数据：

  • 吞吐量比 SOTA 磁盘 ANN 系统高 5.8×。
  • 延迟降低 3.25×。
  • 仅用 10% 内存达到 in-memory 系统 92% 的吞吐量。

DiskANN 路线（DiskANN / VeloANN / OpenSearch ANN / PASE / pg-storm）在活文档 §2.1 已经是一条持续进化的脉络：PASE 是 PostgreSQL 官方 DiskANN 实现（活文档 §2.1 / §2.7），VeloANN 是该路线的 2026 H2 新成员。记录级缓冲池的设计哲学值得复用——它是"按访问粒度而非按页调度 I/O"的典型实现，对 KV cache / 存储系统的设计也有参考价值（与 §2.8 跨引擎 KV cache 主题交叉）。⚠️ 5.8× / 3.25× / 92% 等数字来自单一论文独立实验，尚需第三方复现。

2.4 GPU 混合引擎的反直觉发现

arXiv 2605.15957 · GPU Vector Search in Relational Engines（来源 inbox/jay/2026-07-22-database-e1prep.md 增量 4）

将向量搜索集成到 SQL 关系引擎（TPC-H 扩展 + SQL+VS 查询），在 CPU/GPU、PCIe/NVLink 多种配置下评测，得出反直觉结论：

  • 关系组件从 GPU 中受益比向量搜索组件更大（relational components benefit much more from GPU than vector search）。
  • 整体上 GPU 两者都更快，但 NVLink 互联是决定性因素。
  • 当前专用向量引擎架构未必最优——SQL + 向量混合引擎在 GPU 上可能更高效。

这是活文档 §1 "现状全景" 第 (i) 块（"关系型引擎吞并向量 + 图能力"）方向的重要量化支撑。若该结论成立，意味着未来 AI Database 的架构走向可能是"一体化 GPU 关系引擎"而非"SQL 引擎 + 专用向量 DB"分离路线——这是 2026 H2 数据库架构范式选择的关键不确定性来源。

⚠️ 待核实：该结论来自单一论文，目前尚无独立复现或第三方验证。活文档与本综述同步标注"待核实"，不宜作为确定性结论引用。

2.5 分布式 OLTP 新架构：Aurora DSQL 把解耦推到多区域 active-active

arXiv 2607.13276 · Aurora DSQL: Multi-Region Active-Active OLTP（AWS Marc Brooker 团队，预计 VLDB 2026；来源 inbox/jay/2026-07-22-1105-cross-domains-db-backend-cloudnative-csdn-repro.md §一）

Aurora DSQL 是 AWS 新一代 serverless SQL 数据库，定位为多区域 active-active OLTP，采用完全解耦架构（compute/storage/coordination 分离）：

  • 解耦设计：Query processors 运行在 Firecracker MicroVMs，执行 PostgreSQL 兼容 SQL，无本地状态；存储与协调层均为独立横向扩展服务。
  • MVCC + 精确时间戳：读操作无需协调（coordination-free reads），写操作使用 OCC（Optimistic Concurrency Control），将协调推迟到 commit 阶段。
  • Journal 复制系统：分布式 adjudicator 负责 commit 时协调，最小化跨区域延迟——仅在 commit 时需要协调，单条语句执行无需跨区域通信。

Aurora DSQL ≠ Aurora MySQL/PostgreSQL：后者为 shared-storage 架构，DSQL 为完全解耦。本工作对数据库主线的含义：Journal replication 机制将跨区域协调最小化到 commit 层，是分布式数据库设计的重大参考——它把"协调代价 = 跨区域延迟"这一长期工程难题给出了一个清晰答案。与 TiDB / CockroachDB / Spanner 构成 2026 H2 分布式 SQL "四强对照"（活文档 §2.10 已列 CockroachDB SIGMOD 2026 Scalable Leader Leases 把 lease-maintenance CPU 降低 up to 85%）。⚠️ Aurora DSQL 论文来自 AWS 官方工程团队，架构描述清晰；但具体 benchmark 数字（如跨区域 commit 延迟 P99）建议完整阅读后核实。

2.6 LLM×DB 安全新攻击面：Jailbreak 绕过 DB 引擎

arXiv 2607.07696 · Jailbreak: LLM Reading DB Storage Files（AIDB 2026，VLDB 联会；MIT / Vrije University）

分析型负载通过 JDBC / ODBC 访问数据库存在根本瓶颈——驱动层不适合批量列式分析。Jailbreak 通过 LLM 直接从数据库存储文件（PostgreSQL / MySQL）读取，绕过数据库引擎：

  • LLM 读取数据库文件格式规范（源码 + 文档），生成专用 table reader，无需手工解析逻辑。
  • 在 PostgreSQL 和 MySQL 存储文件上验证，TPC-H 全量查询正确性验证。
  • 端到端分析吞吐量提升最高 27×。
  • 输出格式：Apache Arrow（与 DuckDB / Spark / RAPIDS / cuDF 无缝对接）。

本工作对数据库主线的含义有两层：(a) 正向：LLM 直接读存储文件 + Arrow 输出，确实是 OLAP 性能瓶颈的一个潜在工程化路径，与 RAG 数据层高度相关；(b) 负向：它绕过数据库访问控制（RBAC / 列权限 / 行过滤），构成企业 DB 安全的新攻击面——这是 2026 H2 出现的"DB 安全 + LLM"交叉风险条目。活文档 §2.5 已有 pgvector CVE-2026-3172 高危漏洞记录（Jailbreak 是另一种风险路径）。⚠️ 27× 数字来自 AIDB 2026 同行评审论文，建议等评审完成后确认置信度；目前阶段作为"有潜力，待核实"条目处理。

2.7 RAG 外部库隐私保护：PA-HDP 给出动态分层机制

arXiv 2607.14811 · Is External Database Protection Static in Retrieval-Augmented Generation? Rethinking Privacy Preservation under Dynamic Queries（KB 卡片 paper_cards/429-2607-14811.md，主分类 rag，副分类 database）

RAG 系统中外部数据库的隐私保护长期被建模为静态过程——所有查询应用同一套保护策略。本工作提出 Prompt-Aware Dynamic Hierarchical Differential Privacy（PA-HDP）：

  • Prompt-aware risk hierarchy：动态评估不同查询下的隐私风险等级。
  • Adaptive sensitive entity replacement：根据风险等级做差异化敏感实体替换。
  • Exponential mechanism-based text selection：在保护语义效用的前提下做文本选择。

工程意义：传统 differential privacy 在 RAG 场景下要么过度保护（损失效用）要么保护不足（泄露隐私），PA-HDP 的"prompt-aware"思路把保护粒度从"数据库级"下沉到"查询级"，是 2026 H2 RAG × Database 隐私的代表性新工作。与活文档 §2.5 安全小节互补（pgvector CVE-2026-3172 是 DB 引擎漏洞，PA-HDP 是数据层隐私框架，二者属于不同保护层）。KB 卡片 TLDR 已确认核心机制清晰，但论文完整方法论与实验数据需精读。

2.8 RAG reranking 工程化：Cross-Encoder RAG Reranking

arXiv 2607.11933 · Transforming LLMs into Efficient Cross-Encoders via Knowledge Distillation for RAG Reranking（KB 卡片 paper_cards/485-2607-11933.md，主分类 rag，副分类 llm-infra）

Cross-encoder 在 RAG 流水线中提供高精度 reranking，但推理成本随序列长度二次增长。解法：

  • 用 Unsloth 框架 + LoRA 微调 LLaMA 3 (8B) 作为 drop-in reranker。
  • 4-bit 量化后高效部署。
  • 替换双路检索（BM25 + dense vector search）RAG 流水线中的 cross-encoder。

工程含义：用量化 LLM 替代专用 cross-encoder——是活文档 §2.1 "过滤性能比向量召回率更容易拖垮生产"工程警示的另一条工程化路径（与 §2.1 QVCache 互补：QVCache 解决"向量召回慢"，本工作解决"reranker 重"）。⚠️ 数字（如 reranking 精度提升幅度）需独立复现确认。

三、三视角解读（工程 / 研究 / 批判）

3.1 工程视角（可落地性）

最具落地价值的三件：

  1. QVCache（arXiv 2602.02057）：查询级向量缓存 + bounded recall guarantee；可直接叠加在现有 ANN 系统之上，对"重复 RAG 查询 + 时空局部性明显"的工作负载 40–1000× 尾延迟降低。KB 落地方案：把 QVCache 作为现有向量库前的 query cache proxy，对 RAG / Agent 重复 query 显著的负载立刻可用。
  2. pgvector+pgvectorscale 50M 471 QPS anchor（Salt 2026 Q1，Actian 5 关键测试）：活文档 §2.1 已收录的硬数字，5 源独立确认。KB 决策树已收敛：< 50M + 已有 PG → pgvector+pgvectorscale 是 2026 H2 零决策默认。
  3. Aurora DSQL（arXiv 2607.13276）：多区域 active-active OLTP + journal replication 把跨区域协调最小化到 commit 层——对需要在多区域部署的 SaaS / Agent 后端服务而言，是 2026 H2 分布式 OLTP 选型的新基线参考（⚠️ 仅限 AWS 生态）。

辅助落地三件：

  • Cross-Encoder RAG Reranking（arXiv 2607.11933）：4-bit 量化 LLaMA 3 8B reranker；适合内部 RAG 流水线二次精排。
  • VeloANN（arXiv 2602.22805）：SSD 本地化图 ANN + 10% 内存 = 92% in-memory 吞吐；适合"数据集大于内存但需要低延迟"的成本敏感部署。
  • PA-HDP（arXiv 2607.14811）：RAG 外部库动态差分隐私框架；适合涉及敏感数据的 RAG 场景（医疗 / 法律 / 金融）。

3.2 研究视角（创新性）

最具研究分量的三件：

  1. QVCache 的 bounded recall guarantee：把"工程经验"提升到"理论可证明"。这是 2026 H2 难得一见的"工程创新 + 理论保证"双轮驱动工作。
  2. Filtered ANN Benchmark（arXiv 2602.11443）的 GLS 指标：原创贡献——量化"过滤器与查询向量的相关性"，为后续 ANN × Filtered 工作提供统一度量。
  3. Aurora DSQL 的 journal replication：把"跨区域协调最小化到 commit 层"的工程实践，形式化为可被学术界复用的"完全解耦 + OCC + 精确时间戳 + 集中 adjudicator"组合范式。

辅助创新三件：

  • PG 19 SQL/PGQ（活文档 §2.7）：SQL:2023 标准在 PostgreSQL 中的原生实现——GraphDB 不再是独立选项。
  • VeloANN 记录级缓冲池：把"按访问粒度调度 I/O"的工程思路显式化，与 §2.8 跨引擎 KV cache 设计有交叉价值。
  • PA-HDP 的 prompt-aware risk hierarchy：把 differential privacy 的粒度从"数据库级"下沉到"查询级"，是 RAG × Privacy 的范式创新。

3.3 批判视角（局限）

应当警惕的四条：

  1. GPU 混合引擎的"关系组件 > 向量搜索组件"结论（arXiv 2605.15957）：⚠️ 单一论文、尚未独立复现，不宜作为确定性结论引用。若该结论被推翻，对 AI Database 架构选型的影响会非常显著。
  2. pgvector 成本优化器执行计划异常（Filtered ANN Benchmark）：⚠️ 单一论文独立发现；活文档已标注为"待核实"。生产部署若直接信任该警示而放弃 pgvector，可能错过 pgvector+pgvectorscale 在 < 50M 场景的领先 anchor。建议复现确认后再决定是否上 production alert。
  3. Jailbreak 的 27× 吞吐量提升（arXiv 2607.07696）：⚠️ 数字来自 AIDB 2026 同行评审论文，需等评审完成后确认置信度；同时其"绕过访问控制"的负向量被低估——安全风险与性能收益应同时进入 LLM×DB 风险矩阵。
  4. KV cache × Database 边界混淆：活文档 §2.11 已把"跨引擎 KV cache"明确定位为"边界索引 · 详归 llm-infra.md"。本综述虽然提到 RetroInfer / HNSW-Merger / KV Cache Optimization 综述（arXiv 2603.20397）等工作在 database 主线也有意义，但完整技术解析应回到 llm-infra.md 主题。今天的 database 综述以"边界索引"形式只标注方向，不展开细节。

四、趋势判断与开放问题

4.1 趋势判断（5 条）

  1. 向量 DB 工程化评测成为新热点：QVCache / Filtered ANN / VeloANN / GPU Vector Search 四篇同档期（2602 / 2605）出现，2026 H1 的"新索引算法"红利已经消退，2026 H2 的研究重心转向"工程化系统评测 + 生产优化"。Jay E1 预消化亦观察到"5-6 个月的消化周期"，可作为佐证。
  2. PG 19 GA + SQL/PGQ + pgvectorscale + PASE + pg-storm + HNSW-Merger 形成 2026 H2 pgvector 路线六件套竞合（活文档 §2.7 共识 14）：关系型引擎吞并向量 + 图 + 时序 + JSON 能力，"Postgres absorbs everything"范式 2026 H2 主流化。
  3. 分布式 OLTP 2026 H2 新基线 = Aurora DSQL 解耦架构 + CockroachDB SIGMOD 2026 Scalable Leader Leases：完全解耦 + 集中 adjudicator / shared-nothing + leader lease 优化两条路线并行，构成 2026 H2 分布式 SQL 选型的两条参考路径。
  4. LLM×DB 安全成为独立品类：Jailbreak（AIDB 2026，绕过访问控制）+ pgvector CVE-2026-3172（DB 引擎漏洞）+ PA-HDP（数据层动态差分隐私）三件套，说明 2026 H2 已经出现"DB 安全 + LLM"交叉的独立研究方向。
  5. SIGMOD 2026 班加罗尔 Research-8 "LLM and Vector Retrieval" 单设 session（含 DepCache / KVDrive 两篇 KV cache × GraphRAG 工作）+ HNSW-Merger（Purdue Jianguo Wang Lab 接收）+ VLDB 2026 RetroInfer（MSRA）+ Q-Doctor（华中科技大学 × 阿里）+ BOND = 数据库顶级会议正式把 LLM 服务基础组件（KV cache / RAG 检索）拉回数据库研究范式。

4.2 开放问题（精选 6 条）

  1. GPU 混合引擎"关系组件 > 向量搜索组件"结论的独立复现：决定 2026 H2 AI Database 架构选型走向。⚠️ 待核实，优先级高。
  2. pgvector 成本优化器执行计划异常是否构成生产风险：Filtered ANN Benchmark 单一发现 + 待复现确认。⚠️ 待核实。
  3. Jailbreak 27× 吞吐量提升置信度：AIDB 2026 同行评审论文，评审结果未公布。⚠️ 待评审确认。
  4. Aurora DSQL 与 TiDB / CockroachDB / Spanner 的对比基准：四强对照缺乏第三方独立 benchmark。⚠️ 待独立复现。
  5. PA-HDP 的 prompt-aware risk hierarchy 在生产 RAG 中的端到端开销：差分隐私 + 实体替换 + exponential mechanism 三层叠加对 RAG latency 的影响论文未充分披露。⚠️ 待精读。
  6. 向量 DB "软功夫"价值上升 vs "硬功夫"价值下降的拐点判断（活文档 §2.12 共识 11）：何时 API 表达力 / tool-use 兼容性 / trace export 的边际价值超过索引结构 / 量化 / HNSW 变体的边际价值？当前拐点未明。

五、引用清单与边界声明

5.1 核心综合论文 / 工作（8 篇）

arXiv ID 论文 与 database 主题关系 关键数字
2602.02057 QVCache: Query-Level Vector Caching 向量缓存层 / §2.1 ANN 尾延迟 -40–1000× / 命中 <1 ms / MB 级内存 / bounded recall
2602.11443 Filtered ANN Benchmark (Milvus/pgvector/FAISS/GLS) ANN 横向评测 / §2.1 ANN GLS 指标 / pgvector 优化器异常⚠️
2602.22805 VeloANN: SSD-Locality Graph ANN Index DiskANN 路线 / §2.1 ANN 5.8× 吞吐 / 3.25× 延迟 / 10% 内存 = 92% in-memory 吞吐
2605.15957 GPU Vector Search in Relational Engines GPU 混合引擎 / §1 现状全景 反直觉发现："关系 > 向量" GPU 受益⚠️
2607.13276 Aurora DSQL: Multi-Region Active-Active OLTP (AWS Marc Brooker) 分布式 OLTP / §2.10 / §1 现状全景 Journal replication / 仅 commit 协调
2607.07696 Jailbreak: LLM Reading DB Storage Files (AIDB 2026) LLM×DB 安全 / §2.5 安全 27× 吞吐⚠️ / Apache Arrow 输出
2607.14811 PA-HDP: Prompt-Aware Dynamic Hierarchical DP for RAG RAG 数据层隐私 / §2.5 安全 / §2.8 RAG 动态分层差分隐私
2607.11933 Cross-Encoder RAG Reranking with LLaMA 3 8B RAG reranking 工程化 / §2.1 ANN / §2.8 RAG 4-bit 量化 / Unsloth + LoRA

5.2 顶会信号与活文档锚点（边界索引 · 不展开）

  • SIGMOD 2026 班加罗尔 Research-8: LLM and Vector Retrieval（含 DepCache / KVDrive，pgconf.in/sigmod/sigmod-2026/sessions/34）
  • SIGMOD 2026 HNSW-Merger（Purdue Jianguo Wang Lab）
  • VLDB 2026 RetroInfer（MSRA）+ Q-Doctor（华中科技大学 × 阿里）+ BOND
  • PG 19 GA = 2026-09（postgresql.org/developer/roadmap）+ SQL/PGQ（SQL:2023）+ pgvector 0.8.x + PASE（PG 官方 DiskANN）+ pgvectorscale + pg-storm
  • 活文档 organized/knowledge/database.md 138 个 arXiv ID + 2 CVE（R-17 段，jay 2026-07-19）

5.3 待核实条目汇总

  • GPU Vector Search in Relational Engines（arXiv 2605.15957）反直觉发现 → 单一论文，待独立复现。
  • pgvector 成本优化器执行计划异常（arXiv 2602.11443）→ 单一论文，待独立复现。
  • Jailbreak 27× 吞吐量（arXiv 2607.07696）→ AIDB 2026 同行评审结果待公布。
  • Aurora DSQL 跨区域 commit 延迟 P99 → 论文内部实验数字，建议完整阅读后核实。
  • VeloANN 5.8× / 3.25× / 92% → 单一论文独立实验，建议第三方复现。
  • PA-HDP 端到端 RAG latency 开销 → 论文未充分披露。
  • Cross-Encoder RAG Reranking（arXiv 2607.11933）reranking 精度提升幅度 → 需独立复现确认。

5.4 与其它主题的边界声明

  • RAG 范式与评估：详归 organized/knowledge/rag.md（611 行）。本综述仅在 §2.8 / 2.7 触及 RAG × Database 交叉点。
  • 跨引擎 KV cache：详归 organized/knowledge/llm-infra.md（366 行）。本综述仅以"边界索引"形式标注方向（§2.1 / §2.3），不展开细节。
  • 数据库顶会 SIGMOD / VLDB / CIDR：今天的综述以"边界索引"形式列入 §5.2，完整技术解析以活文档 §2.x 为主。

六、总结

2026 年中后期 "database" 主题在 LLM / Agent 数据层定位上，呈现"三股力 + 一个交叉"的结构：三股力是向量 DB 工程化评测（QVCache / Filtered ANN / VeloANN / GPU Vector Search）、分布式 OLTP 新架构（Aurora DSQL + CockroachDB Scalable Leader Leases）、LLM×DB 安全新攻击面（Jailbreak + PA-HDP + pgvector CVE）；一个交叉是数据库顶会（SIGMOD 2026 班加罗尔 + VLDB 2026 + CIDR 2026）正式把 LLM 服务基础组件（KV cache / RAG 检索）拉回数据库研究范式。这一结构在工程、研究、批判三个视角下都呈现出鲜明的"工程化落地优先 + 理论保证补强 + 顶会学科化"三轨并行的特征——与 2026-07-22 inbox/jay/2026-07-22-database-e1prep.md 的核心判断（"向量 DB 工程化评测 + 分布式 OLTP 新架构 + LLM×DB 安全"）一致，可作为活文档 R-18 段的预备锚点。