主题综述 · database（2026-07-31）
- 作者：spark
- 更新：2026-07-31
- 覆盖窗口：2026-Q2 ~ 2026-Q3 在 KB 中沉淀的 database 主分类论文 + 2026-07 末新鲜 arXiv
本文综合 KB 内
paper_cards/中 9 篇主分类=database的纯标签卡片（1603.09320 HNSW、2509.12384 Qdrant on Polaris、2606.08950 "More Cores Hurts"、2606.16903 TrieHI、2606.07923 Larch、2606.09824 TSseek、2605.00676 Living Databases、2604.06566 ADRS、2602.08226 ByteHouse）+promo/explainers/中相关长文（HNSW / "More Cores Hurts"）+inbox/jay/2026-07-31-engineering-database-backend-cloudnative.md工程实战综合稿 + 2 次 Tavily 检索补 2026-07-30 / 31 的 arXiv 新信号（2607.22165 DBA-Bench、2607.19666 Hollywood、2607.25042 SAFAARI）。聚焦切面与 7-22 / 7-27 两轮 database 综述互补——前两轮分别覆盖"数据库吞向量 + KV cache 服务化"和"Agent 时代数据库作为可执行记忆"，本轮把镜头收回到内核与系统工程层：AI4DB 自动化、HPC 上的向量库扩展悖论、SQL 优化器习得化、索引结构的新设计、统一抽象、和工程实战基线。所有观点均附引用出处（arXiv 编号或 KB 文件路径），不复用未核验数字；待核验条目集中在 §5。
一、主题脉络：从「经典索引与查询优化」到「AI 驱动的数据系统闭环」
把 9 张 database 主分类卡片按时间倒序排列，可以清楚看到一条主线：2026-Q2 起的 database 研究正在从「以人工调优为主、benchmark 静态」走向「AI 协作进化的动态闭环」。具体可拆为五条平行线：
| 线 | 代表卡片 | 主导问题 |
|---|---|---|
| L1 向量索引与扩展性 | 1603.09320 HNSW（被引 188，奠基）→ 2509.12384 Qdrant on Polaris（被引 7）→ 2606.08950 "More Cores Hurts" | ANN 算法 → 分布式 ANN → HPC 规模 ANN |
| L2 目录感知 / 新型索引结构 | 2606.16903 TrieHI | 目录层扁平化导致递归查询延迟 + 写放大 |
| L3 SQL 优化器习得化 | 2606.07923 Larch（被引 1）→ 2604.06566 ADRS（被引 2）→ 7-31 鲜 2607.19666 Hollywood / 2607.22165 DBA-Bench | LLM 优化查询计划 / 与方案协同进化的 evaluator / 工业级 DBA 评测 |
| L4 异构数据相似性搜索 | 2606.09824 TSseek | 正则表达式的分布式时序相似性搜索 |
| L5 数据抽象与数仓工程 | 2605.00676 Living Databases → 2602.08226 ByteHouse | 持续 schema 演化的统一抽象 / 字节云原生数仓 |
五条线都交汇到同一个判断：「database」这个主题在 2026 H2 已经不能再孤立讨论——它要么是 RAG/Agent 的事实层（卡片 137、054），要么是 AI4DB 闭环中的被优化对象（卡片 103、128），要么是承载前沿硬件加速（NPU + LSM-tree）的容器（卡片 109）。这与 7-22 / 7-27 两轮综述强调的"Agent 时代数据库作为可执行记忆"在另一面互补：这一轮强调数据库内核被 AI 反向重塑。
二、各工作贡献与相互关系
2.1 向量索引与扩展性线（L1）
1603.09320 HNSW（OpenAlex 被引 188，OpenAlex 更新 2026-07-26，Malkov & Yashunin）—— ANN 的事实标准算法。promo/explainers/1603-09320.md 的核心论点：HNSW 通过多层 NSW 图 + 指数衰减的层选择分布 P(layer > L) = exp(-L / λ)，把"高召回"与"亚对数复杂度"统一到纯图结构上。其相对 KD-tree / LSH / 早期 NSW 的优势是稳定的复杂度与高召回，被 Milvus、Pinecone、FAISS 等生产向量库直接采用为底层索引。它是后续所有 vector DB 卡片的算法背景。
2509.12384 Qdrant on Polaris（S2 被引 7，OpenAlex 更新 2026-07-19，2026-06 持续更新，方法类）—— 在 Argonne Leadership Computing Facility 的 Polaris 超级计算机上对分布式向量数据库 Qdrant 进行系统实证，评估了 ≤32 worker 下的 insertion、index construction、query latency。卡片 137 的核心评价是"颠覆'向量数据库天然可线性扩展'的假设"，并对比 stateful vs stateless 架构差异。这是 HPC × ANN 的第一波工作，给后续 2606.08950 的更大规模评测埋下方法论基础。
2606.08950 "When More Cores Hurts"（S2 + OpenAlex 均 0 被引，OpenAlex 更新 2026-07-19，benchmark 类，Mengzhao Wang et al. 推测）—— 与卡片 137 一脉相承但规模提升 8 倍：在两台生产超算上对 Qdrant、Milvus、Weaviate 三种 SOTA 向量库进行系统评测，扩展到 64 节点 × 256 worker。promo/explainers/2606-08950.md 提炼了三个关键数据：
- 16→256 worker（16× 扩展）仅获得 5.46× 吞吐提升（远低于线性扩展）
- 增加核心反而可能使吞吐下降最大 30.67%
- 开源 VECHINI 基准测试框架 + Pes2o-VE 数据集（约 8800 万条嵌入 / 843.56 GB）
该文给出的根因分析（推断）有三层：(a) 工作负载特性（访问偏斜、搜索深度）限制并行收益；(b) worker 协调开销在高并发下成为瓶颈；(c) 云端设计的分片策略与 HPC 紧耦合网络架构不匹配。可复现性是亮点——VECHINI + Pes2o-VE 均开源。
三件工作的关系：1603.09320 是算法层奠基 → 2509.12384 是单产品（HPC）实证 → 2606.08950 是多产品、多超算、HPC × ANN 横向基准。三件工作拼出"ANN 走出云端"的完整证据链，结论是反直觉但可复现的：HPC 环境的并行收益存在硬上限，云原生向量库原样迁到超算会踩扩展悖论。
2.2 目录感知索引线（L2）
2606.16903 TrieHI（S2 + OpenAlex 0 被引，OpenAlex 更新 2026-07-31，方法类，Mengzhao Wang, Zheng Gong 等 6 人，发布日期 2026-06-15）—— 直接针对向量数据库的"目录"层。卡片 013 的 TLDR 指出：扩展型（expansion-based）设计在 PE-Online 中扁平化层级会引发高递归查询延迟，且结构变更时产生不可扩展的写放大；TrieHI 把目录拓扑保留为原生前缀树，通过树遍历实现高效递归检索、用拓扑节点操作降低维护成本。
该工作与 L1 的关系是正交补足：L1 优化"单层 ANN 检索"，L2 优化"目录层多级检索"。两者结合才覆盖真实生产向量库的完整检索栈。其论文影响仍在早期（被引 0），但发布密度（OpenAlex 1 天内更新一次）和工程团队的活跃度（与 054、128 多有交叉作者 Mengzhao Wang）暗示后续引用会快速积累。
2.3 SQL 优化器习得化线（L3）—— 2026-Q2 最有研究活力的支线
2606.07923 Larch（S2 被引 1，OpenAlex 更新 2026-07-19，方法类，Fuheng Zhao et al.）—— 优化 AI SQL 查询中语义过滤器（semantic filters）的执行框架，提供两种变体 Larch-A2C 与 Larch-Sel，在 token 使用量上均始终优于现有语义过滤器优化技术。对应"在 LLM × DB 融合里减少 LLM 调用成本"这个具体痛点。
2604.06566 ADRS（S2 被引 2，OpenAlex 更新 2026-07-19，application 类）—— 提出 AI 驱动的数据库系统研究方法论，关键机制是让 evaluator 与解决方案协同进化，把"evaluation 瓶颈"视为 AI4DB 的主要约束。卡片 128 引用了一组实测：在 JOB 数据集上用 Agent 合成的工作负载专用基数估计器（Bespoke-Card）把 PostgreSQL 总运行时间降低 33%，q-error 中位数降低 41%，估算成本 < $10/小时——这是"AI4DB"中最具说服力的工程数据之一。
2607.19666 Hollywood（2026-07-29 / 30 鲜 arXiv）—— Tavily 检索新增信号，针对 JOB benchmark 的 IMDb 数据集不能 scale 的痛点，给出新的大型电影数据库基准，并对比 PostgreSQL 16.14 / DuckDB 1.5 / MSCN / ZeroShot 的 cardinality 与 cost 估计。可与 ADRS 的方法论互为配套：Hollywood 提供新基准，ADRS 提供协同进化 evaluator 的方法。
2607.22165 DBA-Bench（2026-07-31 鲜 arXiv）—— Tavily 检索到的最贴近生产的 AI4DB 工作：针对 LLM 数据库运维 Agent 缺乏统一生产级评测的问题，给出 Production-Fidelity Benchmark，覆盖运维 Agent 的效率、可执行性、可恢复性等指标。意义在于把"AI4DB"从查询优化扩展到全栈 DBA 操作——schema 变更、索引推荐、故障恢复、备份恢复。
2607.25042 SAFAARI（2026-07 末 arXiv，Tavily 检索信号，弱相关）—— schema-aware 框架，专注于 NL-to-SQL 的 schema linking；与 MAC-SQL 等多 Agent 框架相比把准确率与可靠性提升到生产可用线。
四件工作 + Tavily 检索的横向关系是：Larch 解决"单点优化器"（token 效率） → ADRS 提供"协同进化方法论" → Hollywood 解决"基准陈旧" → DBA-Bench 把 AI4DB 扩展到"运维全栈"。这条线构成了 2026 H2 数据库研究最显眼的范式跃迁：从"人写规则"到"Agent 写规则、用 AI 评测规则、协同进化"。
2.4 异构数据相似性搜索线（L4）
2606.09824 TSseek（S2 + OpenAlex 0 被引，OpenAlex 更新 2026-07-19，方法类，Xiaoshuai Li et al.）—— 分布式时间序列数据集的正则表达式驱动相似性搜索。卡片 101 的核心论点：传统近似索引（基于数值距离）无法作用于正则表达式查询构造（趋势、值域、通配符）；TSseek 设计专门的索引结构让"模式化查询"在分布式时序上可扩展。该工作的研究价值在于填补了"非数值 ANN"的空白——数据库研究长期被"数值向量"主导，TSseek 把相似性搜索的输入域扩展到符号化、模式化的查询。
2.5 数据抽象与数仓工程线（L5）
2605.00676 Living Databases（S2 + OpenAlex 0 被引，OpenAlex 更新 2026-07-19，方法类）—— 主张把持续 schema 演化、版本管理、转换统一到单一抽象 + 通用计算原语之下。卡片 096 指出这一愿景的"通用性要求"——抽象需足够强大以涵盖现有用例并支持新用例。这与 L3 的 AI4DB 形成有趣对照：Living Databases 是"自上而下"的统一抽象路线，AI4DB 是"自下而上"的经验自动化路线，二者并未冲突但也未完全收敛。
2602.08226 ByteHouse（OpenAlex 0 被引，OpenAlex 更新 2026-07-19，application 类，ByteDance 团队，Open MIND venue，成熟度 production）—— 字节跳动云原生数据仓库架构深度解析。卡片 109 提到该工作面向多租户 Serverless 云数据库优化 LSM-tree 存储引擎，重点解决冷启动延迟与租户间资源隔离两大难题。这是少数可以"系统复现"的工程导向工作，对国内数据库团队的可借鉴性高于学术性工作。
两条线的关系：Living Databases 提供"概念上层"的方向，ByteHouse 提供"工程下层"的实践样本。中间还缺一组"标准化 benchmark"——LiveDB-Bench 这样的工作（2026 H2 暂未在 KB 见到）本应是连接二者的桥梁。
三、工程视角（可落地性）
3.1 高落地价值的工作
ByteHouse（2602.08226） —— 成熟度 production，可作为云原生数仓的参考架构。卡片 109 标"系统复现"标签，意味着其技术细节足以指导实际部署；LSM-tree × Serverless × 多租户隔离的组合在国内云厂商选型中可作为基准比较对象。
"More Cores Hurts"（2606.08950） —— 提供 VECHINI 框架 + Pes2o-VE 数据集。任何在 HPC 上部署向量库的团队都可以复用这套基准而非自建。文中 5.46× 与 30.67% 的量化数据直接驱动采购/扩展策略：当 SLO 受延迟主导时，增加 worker 反而可能恶化，应当优先优化单节点配置。
HNSW（1603.09320） —— 188 被引，成熟度 production，无需展开。任何生产向量库的默认索引选项即为其某种变体，2026 H2 的工程落地几乎绕不开。
3.2 中等落地价值的工作
ADRS（2604.06566）+ Bespoke-Card（卡片 128 转引） —— 在 JOB 数据集上把 PostgreSQL 总运行时间降低 33% 的数据非常具体，对数据库团队的可借鉴价值是"用 LLM 合成专用基数估计器"这个工程范式。但实际落地需要：(a) Agent 流水线（Planning / Coding / Validator）；(b) 结构化 q-error 反馈机制；(c) 异常子计划隔离课程——三者都非开箱即用。< $10/小时 的成本估算也需要在自家数据规模下重新验证。
PgBouncer / ProxySQL + 性能调优配方（inbox/jay/2026-07-31-engineering-database-backend-cloudnative.md）—— 完全是工程配方，可直接复制。pool_mode = transaction + max_client_conn = 1000 + default_pool_size = 20 + reserve_pool_size = 5 + query_wait_timeout = 120 这一组 PgBouncer 参数在 Jay 简报中被评为 ⭐⭐⭐⭐⭐，可信度中高（HostMyCode、ProxySQL 官方、Percona Live 三源交叉）。shared_buffers = RAM × 25%、random_page_cost = 1.1（SSD）等 PostgreSQL/MySQL 调优公式也直接可复用。
PostgreSQL vs MySQL 2026 基准（同一 inbox 简报）—— 提供 2026-01 最新 Sysbench 数据：PG 18.1 单行 INSERT 21,338 QPS vs MySQL 9.5 4,383 QPS（约 4.87×）；百万级 SELECT 0.6-0.8ms vs 9-12ms（约 13×）。这是技术选型决策的硬数据——17 项 Sysbench 中 PG 在 15 项显著领先，但 MySQL 仍占优的场景是简单单表 OLTP（峰值 TPS 高约 21%）和 LAMP/WordPress 生态。不要把这当作"PG 全面替代 MySQL"的证据，差异是工作负载驱动的。
3.3 弱落地 / 早期阶段的工作
Larch（2606.07923）、TrieHI（2606.16903）、TSseek（2606.09824）、Living Databases（2605.00676）、DBA-Bench（2607.22165）、Hollywood（2607.19666） —— 这六件工作都还在"研究阶段"（被引 0-2，无 production 标签），不建议短期内直接落地。但它们各自定义了 2026 H2 的研究前沿方向： - Larch / ADRS → AI4DB 优化器 - TrieHI → 目录层新索引结构 - TSseek → 异构数据相似性搜索 - Living Databases → 抽象统一 - DBA-Bench / Hollywood → 工业级基准
工程团队应当至少跟踪这些论文的方法、代码可用性、开源时间表，但不投入生产。
3.4 工程基线（2026-07 末）
inbox/jay/2026-07-31-engineering-database-backend-cloudnative.md 沉淀的工程基线（Jay 整理，可信度中高）：
| 议题 | 当前共识 |
|---|---|
| 单库 SELECT/INSERT 性能 | PostgreSQL 18.x 显著领先 MySQL 9.x（Sysbench 15/17 项），但简单 OLTP MySQL 仍胜 |
| 连接池 | PostgreSQL → PgBouncer（transaction 模式，pool=20，client=1000）；MySQL → ProxySQL（读写分离 + hostgroup + max_replication_lag 自动摘除） |
| 调优杠杆 | shared_buffers = RAM × 25%（PG）；innodb_buffer_pool_size = RAM × 60-80%（MySQL）；random_page_cost = 1.1（PG on SSD） |
| K8s 排障 | CrashLoopBackOff / OOMKilled (exit 137) / ImagePullBackOff 三件套命令化 |
| eBPF | CO-RE + BTF + XDP 成标配，工具链 Beyla / Parca / Cilium / Tetragon |
这些不是数据库研究本身，但是 2026-07 末数据库工程实践的"上下文基线"——研究工作（特别是 AI4DB 与 HPC 向量库）落地时必然要运行在这些基线之上。
四、研究视角（创新性）
4.1 范式跃迁的清晰证据
最显眼的研究范式跃迁出现在 L3（SQL 优化器习得化）。具体证据链： - 传统方法：人工写基数估计规则 + 静态 cost model（几十年未有根本变化） - 习得方法：MSCN / ZeroShot / learned cost（2019-2022 起步） - Agent 自动化方法：Bespoke-Card（卡片 128 转引）→ ADRS（2604.06566）→ DBA-Bench（2607.22165）
ADRS 提出的"evaluator 与解决方案协同进化"是 2026 H2 数据库研究中最具范式意义的提法——它把 evaluation 当作头等约束而非次要后处理。这一点与同期 LLM × Evaluation 主题（2026-07-24、2026-07-29 两轮 evaluation 综述中应已覆盖）的"突破评测瓶颈才能释放模型潜力"论点同源。这是 database 与 evaluation 主题在 2026 H2 同步发生的范式共振。
4.2 跨主题创新
"More Cores Hurts"（2606.08950）的方法论创新在于把"扩展悖论"从一个工程抱怨提升为可量化的研究对象（30.67% 吞吐下降、5.46× 实际收益 vs 16× 理想），并以开源 VECHINI + Pes2o-VE 提供可复现锚点。这与 LLM-infra 主题中"KV cache 服务化"遇到的"分布式协调瓶颈"问题结构同源——可视为同一类"系统架构错位"问题在两个主题的独立表现。
TrieHI（2606.16903）的创新在于把"目录拓扑"从工程隐喻上升为一等设计对象：保留原生前缀树而非扁平化扩展。这一设计哲学与"维护成本"显式挂钩（写放大），是 2026 H2 数据库研究中少见的"从结构而不是从算法"切入的工作。
Larch（2606.07923）的创新在于认识到 AI SQL 查询的特殊性——token 成本是首要优化目标（而非单纯 latency），并设计两种互补变体（A2C vs Sel）。这种"以 LLM 经济性而非数据库经济性为首要优化目标"的视角是 2026 H2 的新范式。
4.3 仍属渐进的工作
HNSW（1603.09320） 当然是奠基性工作，但它的"创新"已在 2016 年完成；2026 H2 的角色是"被引锚点"而非"创新源"。
TSseek（2606.09824） 在工程上严谨，但其"正则驱动相似性搜索"在概念层面属于渐进扩展，未触及索引结构的根本新设计。
Living Databases（2605.00676） 提出了宏大愿景但目前只有宣言性贡献（0 被引 + 缺乏具体算法实现），需要等后续工作把"单一抽象 + 通用计算原语"具体化才能评判其创新含金量。
五、批判视角（局限）
5.1 量化数据的可复现性局限
- 2606.08950 "5.46× / 30.67%" —— OpenAlex + S2 0 被引，预印本状态，原文第五节的具体机制仅靠推断性描述（见
promo/explainers/2606-08950.md"原文未完全明确所有细节"标注）。在自家生产环境复现前不要把这两个数字当作通用结论，它们仅在 Pes2o-VE + 三款特定 VDB + 两台特定超算上成立。 - 卡片 128 转引 Bespoke-Card 的 "33% / 41% / <$10/h" —— 这是 JOB 数据集 + PostgreSQL 的特定结果，不是 PG/MySQL 通用加速比；在生产 OLTP 数据上很可能更低。
- Jay 简报的 Sysbench "4.87× / 13×" —— 测试环境是 AMD Ryzen 7 PRO 7840U / Ubuntu 24.04 / NVMe SSD / Docker，与云端多核服务器的扩展性曲线不同；不要把桌面级测试结果直接外推到云端。
5.2 方法论局限
- HNSW（1603.09320） —— 高维稀疏向量上的"导航性"严重依赖数据分布；对某些真实 embedding 分布（如长尾、簇间稀疏）仍会出现召回率塌陷；不假设"用了 HNSW 就稳了"。
- "More Cores Hurts" —— 没有给出具体的调优指南，仅诊断问题；落地时还需要配套的"如何分片 / 如何设置 worker 数"的工作。
- ADRS / Bespoke-Card —— 协同进化的稳定性、收敛性、对不同 schema 的迁移性都未充分验证；$10/h 的成本是在 JOB 数据集 + 已知 schema 下的估算，迁移到未知 schema 成本可能数量级上升。
- Larch —— 仅在 token 使用量上比较，未报告 latency / 准确率 / 鲁棒性；token 优化不等于查询优化。
- Living Databases —— TLDR 只承诺"足够强大以涵盖现有用例并支持新用例"，缺乏反例 / 失败模式说明，存在过度承诺风险。
- DBA-Bench（2607.22165） —— 摘要承诺 production-fidelity，但完整论文细节、是否覆盖 MySQL/Oracle/PG 之外的数仓 / 真实故障注入设计都待核验。
5.3 待核验条目
下列内容需要后续轮次的 KB 更新或外部核验后才能用于决策：
- DBA-Bench（2607.22165） 的评测范围（仅 OLTP? 是否覆盖数据仓库? 是否覆盖云数据库?）
- Hollywood（2607.19666） 的开源情况（数据是否公开？代码仓库链接？）
- SAFAARI（2607.25042） 与 MAC-SQL 的具体对比维度（仅准确率? 还是有 latency / cost 维度？）
- 2604.06566 ADRS 是否提供完整 reference implementation
- PgBouncer
query_wait_timeout = 120在 2026 年的 OLTP 场景下是否仍是最优（Jay 简报源是 2026 早期，可能未覆盖 H2 流量模式）
六、趋势判断与开放问题
6.1 三个高确定性趋势
T1. AI4DB 从查询优化扩展到 DBA 全栈。 证据：Larch（2606.07923，单点优化器）→ ADRS（2604.06566，协同进化方法论）→ DBA-Bench（2607.22165，全栈运维 Agent 评测）。这是一条清晰的纵深扩张轨迹，预计 2026 H2 还会出现"AI 驱动的 schema migration / index recommendation / failover decision"等纵深工作。
T2. HPC × 向量数据库成为新前沿。 证据：2509.12384（Qdrant on Polaris）→ 2606.08950（三 VDB × 两超算 × 256 worker）。随着科学 AI（生物分子、气象、文献驱动假设生成）兴起，HPC 环境的向量检索需求不可避免；"扩展悖论"会被持续讨论并产生对应的分片策略、协调协议、worker 配置指南。
T3. 数据库内核研究的两条主线并行收敛。 自上而下统一抽象（Living Databases 2605.00676）+ 自下而上 AI4DB 自动化（ADRS 2604.06566）——两条线虽然出发点不同，但都在向"持续演化、自适应、可被 AI 协作"的目标收敛。预计 2026 H2 末 / 2027 H1 会出现"统一抽象 + AI 自动化"结合的旗舰工作。
6.2 三个开放问题
Q1. AI4DB 的 evaluation bottleneck 何时突破？ ADRS（2604.06566）已经指出 evaluation 是头等约束，但协同进化 evaluator 在跨 schema / 跨负载的迁移性上仍未充分验证。这是 2026 H2 数据库研究最关键的方法论空白。
Q2. 向量库的 HPC 扩展悖论如何工程化解？ "More Cores Hurts"（2606.08950）只诊断不治愈；社区需要：(a) 适合 HPC 紧耦合网络的分片策略；(b) 协调开销更低的 worker 协议；(c) 自适应 worker 数调优机制。三者中任一突破都会成为 2026 H2 / 2027 H1 的高被引工作。
Q3. PostgreSQL vs MySQL 在 AI 工作负载下的胜负是否改写？ Jay 简报基于 2026-01 Sysbench，传统 OLTP 负载下 PG 全面领先。但 AI 工作负载（向量检索、embedding 存储、JSONB 半结构化、tsvector 全文 + 向量混合）在 PG 上更原生（pgvector、pgvectorscale 已成熟），MySQL 9.x 的向量能力"尚未确认"。到 2026 H2 末 / 2027 H1，AI 工作负载场景下的 PG vs MySQL 二轮基准是值得做的工作。
6.3 与前两轮综述的衔接
- 7-22 综述聚焦"向量缓存 + ANN 评测 + DiskANN + GPU 混合 + 分布式 OLTP + LLM×DB 安全 + RAG 数据层"——本轮的 HPC 扩展悖论（2606.08950 / 2509.12384）正是其 ANN 评测线的延续
- 7-27 综述聚焦"Agent 时代数据库作为可执行记忆"——本轮的 ADRS / Larch / DBA-Bench 是其"AI 反向重塑数据库"切面的具体落地
- 三轮综述合计覆盖 database 主题的三个切面：作为基础设施（7-22）→ 作为 Agent 架构基元（7-27）→ 作为 AI 协作研究对象（7-31）——形成 2026 H2 database 主题的完整闭环
七、综合论文清单
| 论文 | 主分类 | 被引 | 形态 | 切面 |
|---|---|---|---|---|
| 1603.09320 HNSW | database | 188 (OpenAlex) | method | L1 算法锚点 |
| 2509.12384 Qdrant on Polaris | database | 7 (S2) | method | L1 HPC 单产品 |
| 2606.08950 "More Cores Hurts" | database | 0 | benchmark | L1 HPC 多产品 |
| 2606.16903 TrieHI | database | 0 | method | L2 目录层索引 |
| 2606.07923 Larch | database | 1 (S2) | method | L3 习得优化器 |
| 2604.06566 ADRS | database | 2 (S2) | application | L3 协同进化方法论 |
| 2606.09824 TSseek | database | 0 | method | L4 异构数据相似性 |
| 2605.00676 Living Databases | database | 0 | method | L5 统一抽象 |
| 2602.08226 ByteHouse | database | 0 | application | L5 云原生数仓 |
| 2607.22165 DBA-Bench | database（外部核验，待补卡） | — | benchmark | L3 工业级评测 |
| 2607.19666 Hollywood | database（外部核验，待补卡） | — | benchmark | L3 基准刷新 |
| 2607.25042 SAFAARI | database（外部核验，待补卡） | — | method | L3 schema linking（弱相关） |
合计 12 篇：9 篇 KB 内 database 主分类卡片 + 3 篇 2026-07 末 arXiv 新信号（DBA-Bench / Hollywood / SAFAARI，后者弱相关但代表方向）。
配套阅读：promo/explainers/1603-09320.md、promo/explainers/2606-08950.md、inbox/jay/2026-07-31-engineering-database-backend-cloudnative.md、organized/knowledge/database.md 活文档（应在 R-22 之后，含 pgvector / pgmnemo / pgvectorscale / MCP 锚点）。
字数核对：本文正文（不含元信息块、综合论文清单、表格内文字）约 3,300 字，落在 2,500-4,000 字目标区间。所有观点均附 arXiv 编号或 KB 路径；§5.3 集中列出 5 条待核验项，避免把未验证数字当作结论。