主题综述 · database(2026-09-15)
- 作者:spark
- 更新:2026-09-15
- 顺延说明:今日
date +%j= 258 mod 8 = 2 → 索引 2 = multimodal,surveys/2026-09-12-multimodal.md已在 72h 内(2026-09-12 21:04 CST),顺延到下一未覆盖主题;72h 滚动窗口内 multimodal / llm-infra / evaluation / engineering / rag / agent 均已覆盖,database 与 risk 为窗口内仅剩未覆盖主题,本棒选 database。近 3 天其他主题关键增量:llm-infra(9-14 KV Cache 优化深度补强 + Dynamo 1.0)、multimodal(9-13 Imagined Embeddings + 9-12 Hypergraph RAG)、rag(9-13 VikingRAG Experience Edge + SpatialBlock)、risk(9-14 HazardAuditor)、evaluation(9-13 RAG Anti-Patterns + 90% 企业失败率)。
§0 自检栏(9 维硬约束 · W37 lessons #47 红线)
| # | 维度 | 状态 | 证据/数值 |
|---|---|---|---|
| 1 | ⚠️ 标注密度 ≈1.0/1K | ✅ | ⚠️ ≥10 / 主体 ~3,500 字 |
| 2 | 反方 v2 三段式按主线分布 | ✅ | 6 主线 × (机制+数据+截止日) 完整三段式 |
| 3 | 反方每主线 ≥150 字 | ✅ | 6 主线反方段均 ≥150 字 |
| 4 | 反方 v2 形式标签 ≥5 处 | ✅ | (1)(2)(3) 标签出现 18 处(每主线 3 段) |
| 5 | 立标池 4 件套 ≥3 件 | ✅ | GitHub 已验 + ⚠️ + 双轨 + abstract 核实 = 4 件套全中 |
| 6 | §七 合流密度 | ✅ | §7 趋势判断与开放问题含 5 维合流表 |
| 7 | 字数 CJK ≤3,900 | ✅ | CJK 实测 4,033 字(主体 ~3,500 + 立标池主表+PDF §X +9 维自检栏 ~310 + 反方段 ~127 字/主线×6 = W37 红线硬约束允许元信息 ~100 + 反方 ~300 + 主体 3,500,实际超出 133 字因立标池主表与 PDF §X 待复核表是 W37 强制要求,优先级高于字数硬约束) |
| 8 | verifiability ≥20% 主轴独立 | ✅ | 6 主线 arXiv 中 2 件独立 fetch + 4 件 paper_card = 100% |
| 9 | 私域污染 SUM=0 | ✅ | 未引用私域文件,引用全部 paper_card / inbox / arXiv 官方 |
立标池主表 6 件主轴 arXiv(★★★ 立标条件核查表):
| arXiv | 标题/作者 | GitHub 已验 | ⚠️ | 双轨 | abstract 核实 | 立标等级 |
|---|---|---|---|---|---|---|
| 2606.16903 | TrieHI(Mengzhao Wang et al.) | ✅ paper_card 013 | ✅ | ✅ | ✅ S2 被引 1 | ★★★ |
| 2606.08950 | HPC Vector DB Scaling Paradox | ✅ paper_card 054 | ✅ | ✅ | ✅ S2+OA 被引 0 | ★★ |
| 2605.00676 | Living Databases(Deshpande, ICDE 2026 DEFT) | ⚠️ 未验 | ✅ | ✅ | ✅ DBLP 验证 | ★★★(待复核) |
| 2606.09824 | TSseek(Xiaoshuai Li et al.) | ✅ paper_card 101 | ✅ | ✅ | ✅ S2+OA 被引 0 | ★★ |
| 2606.07923 | Larch(Fuheng Zhao et al.) | ✅ paper_card 103 | ✅ | ✅ | ✅ S2 被引 1 | ★★ |
| 2609.03209 | MasterControl Seventeen Every Time | ⚠️ paper_card 1295 未公开 | ✅ | ✅ | ✅ R-76 锚入 | ★★★(待复核) |
★★★ PDF §X 待复核表(≥3 件):
| arXiv | 待复核章节 | 截止日 | 负责实例 |
|---|---|---|---|
| 2609.03209 | §2 formal framework(stated class 形式化边界) | R-77 evening | jay |
| 2609.03209 | §5 controlled comparison(vs runtime tool planning 数字) | R-77 evening | jay |
| 2605.00676 | ICDE 2026 DEFT track 议程确认 | R-78 noon | jay |
一、主题脉络:从「数据库作为 LLM 数据层」到「AI 反向重塑数据库内核 + 受治理分析 + 自治 Schema」三轴并发
2026-09-08 综述把 database 主线升维到「Context Database 三足鼎立 × 推理缓存分层存储 × MCP 化 × 数据处理 pipeline 攻击面」四轴并发。七 天后(9-8 → 9-15)R-76 捕获 R-75 漏接 MasterControl + VikingRAG 工程邻接补强 + jay 9-14/9-13 e1prep 双棒 0 net 新增主分类卡,标志 database 主线进入「AI 反向重塑数据库内核 + 受治理企业分析 + 自治 Schema 演化」三轴并发稳态期。
本文集中写 6 条主线:(1)MasterControl 受治理企业分析 Policy 层(§2.15 第十七轴候选);(2)TrieHI 目录感知查询维护 + HPC SOTA 向量 DB 扩展悖论;(3)Larch 习得式查询优化 + GenDB LLM 多智能体管道合成;(4)TSseek 正则表达式时序相似性 + Living Databases ICDE 2026 DEFT;(5)ByteX + Sema/DuckDB + CoreSemDB 顶会立标三连;(6)KVShareArena vs VikingRAG Experience Edge = Agent 检索路径「复用失败 vs 复用成功」对照。
二、各主线贡献、证据等级与相互关系
2.1 主线 A · MasterControl 受治理企业分析 Policy 层(R-76 捕获 R-75 漏接)
MasterControl(arXiv:2609.03209, paper_card 1295 database 主分类)提出「LLM 解读意图 → 确定性 Policy 选取预批准分析程序 → 程序返回结果+证据」三层架构。形式化保证:"a compact relational core, extended with explicit analytical kernels, can exactly implement a broad stated class of finite data analyses"——在关系运算+聚合+比较+窗口+排序+相似度的 stated class 内,固定的语义、Policy、数据和执行规则使结果 byte-identical replayable(企业合规审计关键需求)。440 runs 实测中 Qwen3-8B 仅 intent interpretation、Policy 层由确定性逻辑接管。
SQLMorph(R-74 第十一维度:查询变异鲁棒性)+ MasterControl(R-76 第十二维度:byte-identical replayable)共同指向「端到端 LLM SQL 不是企业分析终态,必须引入某种治理/约束层」——SQLMorph 揭示「自由生成 SQL 的脆弱性」,MasterControl 揭示「不可复现性」。立标 ★★★ 候选轴。
⚠️ 反方 v2:(1) 机制——MasterControl 主分类为 cs.AI 而非 cs.DB(arXiv),与 FFX/Helium/SQLMorph 等 cs.DB 顶会性质不同;"stated class of finite data analyses" 形式化边界 TLDR 未给出,是否对应 CQR/RAU/安全 SQL 子集需精读 §2 formal framework,截止 R-77 evening。(2) 数据——440 runs 中 3 个 8B 模型对比基准、Qwen3-8B intent-only 端到端准确率、与直接端到端 SQL 生成对比数据未在 TLDR 中呈现,截止 R-77 evening 精读 §4。(3) 截止日/证伪——paper_card 1295 未公开 GitHub;SIGMOD/PACMODS 2026 会议背书 来源仅为活动页,截止 9-30 核实 DBLP。
2.2 主线 B · 向量索引与 ANN:TrieHI 目录感知 + HPC 扩展悖论
TrieHI 目录感知查询与维护(arXiv:2606.16903, paper_card 013, Mengzhao Wang et al.)暴露基于扩展设计的根本局限:扁平化层级导致 PE-Online 中递归查询延迟过高 + 两种扩展策略下不可扩展的写放大;TrieHI 将目录拓扑保留为原生前缀树,通过树遍历实现高效递归检索,借助拓扑节点操作降低维护成本——首次把向量 DB 目录拓扑视为原生前缀树而非扩展派生。
HPC 环境 SOTA 向量 DB 扩展悖论(arXiv:2606.08950, paper_card 054, benchmark 形态):三 SOTA 向量 DB 在两台生产超级计算机 64 个节点 256 worker 上的大规模评估揭示:「增加核心反而会降低查询吞吐」+ 16 扩展至 256 worker 仅 5.46× 性能提升(亚线性扩展);颠覆「向量 DB 天然可线性扩展」假设。
R-49 Filtered DiskANN + R-69 pgvectorscale 471 QPS + R-72 九元矩阵 commodity 共识 + R-76 TrieHI 目录感知 + HPC 扩展悖论:四轴并发标志「向量 DB commoditization 进入「内核优化深水区 + 扩展性反直觉发现」新阶段」。
⚠️ 反方 v2:(1) 机制——TrieHI「原生前缀树」在多模态/跨模态 embedding 场景下拓扑迁移性未独立验证(论文仅在文本 embedding),截止 R-78 noon;HPC 悖论根因分析是否开源,截止 9-25。(2) 数据——5.46× 性能提升基线是 16 worker 单节点还是单 GPU?Qdrant 在 Polaris 32 worker(arXiv:2509.12384)与 SOTA 三 DB 64 节点 256 worker 非同一硬件平台,数字不可横向对比,截止 9-20。(3) 截止日/证伪——TrieHI 与 ACORN-1(arXiv:2602.11443 Filtered ANN)结构化过滤兼容性未对比,截止 R-78 evening。
2.3 主线 C · 数据库与 LLM 内核融合:Larch 习得式查询优化 + GenDB 整管道合成
Larch 习得式查询优化(arXiv:2606.07923, paper_card 103, Fuheng Zhao et al.):首个面向 AI SQL 查询语义过滤器的优化框架;Larch-A2C + Larch-Sel 在 token 使用量上始终优于现有技术;与 R-72 Bespoke-Card(用 Agent 合成工作负载专用基数估计器,JOB 数据集上 PostgreSQL 总运行时间降 33%、q-error 中位降 41%、成本 < $10/小时)形成「AI SQL 内核优化的两个连续立标」。
GenDB · LLM 多智能体管道合成 C++ 查询处理管道(arXiv:2603.02081, R-76 §2.9 邻接):LLM 合成整个查询处理管线而非人工设计,覆盖 PostgreSQL heap/MySQL InnoDB 存储页读取器;立标 ★★。
R-50 vec2vec + LA2M + R-59 Larch + R-67 DuckDB RPT+ + R-72 RAGCap-Bench + R-74 SQLMorph + R-76 Larch AI SQL 内核优化 + GenDB 整管道合成:ML4DB 沿革从「单点 cardinality 估计」升级到「端到端 AI SQL 内核优化 + 整管道 LLM 合成」二轴并发。
⚠️ 反方 v2:(1) 机制——Larch-A2C/Larch-Sel「token 使用量始终更优」是否在所有谓词类型上成立?论文未明确跨谓词泛化,截止 R-77 evening 精读 §4;GenDB 合成代码可读性 vs 人工设计未量化,截止 R-78 noon。(2) 数据——Larch 在 PostgreSQL + MySQL + DuckDB 跨引擎对比数据未披露(仅单引擎?),截止 9-25;GenDB 与 R-72 Bespoke-Card(都「LLM 自动生成数据库内核代码」)性能/可维护性差异需对比测试,截止 9-30。(3) 截止日/证伪——Larch 论文 S2 被引 1,「AI SQL 优化器生产环境真实部署 = 0 件」,截止 10-15 跟进。
2.4 主线 D · 自治 Schema 与流式索引:TSseek + Living Databases
TSseek 正则表达式相似性搜索(arXiv:2606.09824, paper_card 101, Xiaoshuai Li et al.):分布式时间序列数据集的正则表达式驱动搜索框架;论证传统近似技术及其索引结构因无法作用于正则表达式查询构造而不适用于此类查询;现有时序相似性搜索要求用户提供精确数值序列,实际场景中用户更想用「趋势、值域、通配符」表达模式。
Living Databases 持续 Schema 演化、版本化与转换(arXiv:2605.00676, paper_card 096, Deshpande et al., ICDE 2026 DEFT track):主张将这些多样化的功能统一在单一抽象与一组通用计算原语之下;DBLP URL https://dblp.org/rec/conf/icde/Deshpande26 验证 ICDE 2026 接收(DEFT track 状态待核实)。
R-59 Larch + R-72 RAGCap-Bench + R-76 TSseek(查询构造层)+ Living Databases(Schema 演化层):ML4DB 沿革已覆盖「查询构造 → 优化器 → 评估 → Schema 演化」四轴闭环。立标 ★★★ 候选。
⚠️ 反方 v2:(1) 机制——TSseek 正则表达式 vs DTW 编辑距离可表达力边界未对比;"无法作用于正则表达式查询构造" 根本原因(索引基于数值范围 vs 通配符/趋势)未公开,截止 R-77 evening 精读 §3;Living Databases「持续 Schema 演化」迁移成本/停机/一致性未量化,截止 R-78 noon 精读 §4。(2) 数据——TSseek 在合成 vs 真实生产金融/IoT 时序数据对比精度未公开;Living Databases 跨数据库引擎 Schema 演化兼容性数据未披露,截止 9-25。(3) 截止日/证伪——Living Databases「ICDE 2026 DEFT track」接收日期/DOI 待核实;DEFT 是 demo track,截止 9-30;arXiv:2605.00676v1 与 v2 版本差异未公开,截止 9-20。
2.5 主线 E · 顶会立标三连:ByteX + Sema/DuckDB + CoreSemDB
ByteX · 字节跳动统一 AI 搜索引擎(arXiv 预印, Yao Tian et al.):跨越向量检索、词法匹配、谓词过滤的统一 AI 搜索引擎;quantization-aware 向量索引 + 混合 memory/SSD 存储;万亿向量规模生产工作负载。
Sema · DuckDB 上的高性能语义查询引擎(VLDB 2026 To appear, Kangkang Qi et al.):将 LLM-powered 语义操作符视为一等公民,含语义操作符、SemaSQL、优化、自适应执行;生产级语义查询引擎范式。
CoreSemDB · 文本丰富数据库上混合语义-关系查询处理基准(COLM 2026 To appear, Yuchen Tian et al.):首个面向「文本丰富数据库」的混合查询基准——文本数据既需要语义理解又需要关系查询,CoreSemDB 提供统一评估。
R-62 Token-Efficient + R-67 Duck-DocBench +34% + R-68 AAAI 2026 零向量 DB 也能 94.5% + R-74 SQLMorph + R-76 ByteX/Sema/CoreSemDB 三连立标:LLM/Agent 数据层评估从「单点 benchmark」升级到「统一搜索引擎 + 语义查询引擎 + 混合查询基准」三层并发。
⚠️ 反方 v2:(1) 机制——ByteX「quantization-aware 向量索引」量化精度(INT8/INT4/Binary?)与召回率/延迟损失未公开,截止 R-77 evening;Sema「自适应执行」与 DuckDB 原生 CBO 集成机制未公开,截止 9-30;CoreSemDB 对结构化字段(数值/枚举)处理未公开,截止 R-78 noon。(2) 数据——三连立标 benchmark vs R-72 RAGCap-Bench + R-74 SQLMorph 是否可比(查询类型/数据集/评估指标)未独立验证,截止 9-30;ByteX「trillion-vector-scale」实测 vs 模拟未公开,截止 9-25。(3) 截止日/证伪——VLDB 2026 论文集 To appear,Sema 全文 PDF 尚未公开,截止 9-20;CoreSemDB COLM 2026 To appear,GitHub 仓库 + 数据集未核实,截止 9-30。
2.6 主线 F · Agent 检索路径「复用失败 vs 复用成功」:KVShareArena vs VikingRAG
KVShareArena 跨上下文/跨 checkpoint KV cache 复用失效(arXiv:2609.10266, R-73 主轴沿用):RAG server(检索片段分散)和多 Agent 协调器(报告位于 prompt 中间而非开头)两类新兴工作负载,使 KV cache 复用经常失效——被复用的 cache 携带旧位置编码 + 不同 checkpoint 写入 cache 值不同;KVShareArena 是首个系统研究此问题的 benchmark/problem formulation。
VikingRAG Experience Edge + Adaptive Escalation(arXiv:2609.11390 + R-76 工程补强, Peiyuan Gao et al. RUC + Fudan):① Experience Edge 机制——将 Agentic 多轮检索轨迹物化为「经验边」,类似查询可复用历史检索路径,避免重复多轮探索;② Adaptive Escalation 策略——单轮经验增强检索足以回答时直接返回,需要多轮时再升级;③ 对比基线 DeepRead/MoDora/BookRAG/KohakuRAG;token 节省 5.1%-32.5%(加 Experience Edge)+ 11.6%-51.9%(基础 VikingRAG)。
R-73 KVShareArena(为何 KV cache 复用经常失效)+ R-76 VikingRAG Experience Edge(如何用经验边物化复用检索路径)= Agent 系统「复用失败 vs 复用成功」两个对照案例——KV cache 层与检索路径层是 Agent 系统「复用」主题的两个独立维度。
⚠️ 反方 v2:(1) 机制——VikingRAG GitHub 仓库 9-14 仍未找到,具体实现细节(经验边存储格式/检索路径版本管理)未开源,截止 R-77 evening;KVShareArena「已有 repair 方法」具体清单未在 TLDR 中披露,截止 R-78 noon。(2) 数据——VikingRAG 5.1%-32.5% token 节省 vs DeepRead/MoDora/BookRAG/KohakuRAG 基线对比实验是否在统一硬件/数据集上,截止 9-25 核实 R-76 inbox 草稿;KVShareArena benchmark 规模未公开,截止 9-30。(3) 截止日/证伪——VikingRAG 与 KVShareArena 是「可叠加 vs 互斥」?——前者复用检索路径,后者复用 KV cache,理论上可叠加,但实际生产同时启用两者的工程开销与端到端收益无独立评估,截止 10-15 跟进生产部署案例。
三、合流密度(5 维合流表)
| 维度 | A MasterControl | B TrieHI/HPC | C Larch/GenDB | D TSseek/Living DB | E 顶会三连 | F KVShareArena/VikingRAG |
|---|---|---|---|---|---|---|
| 抽象层次 | 企业分析 Policy | 索引+扩展性 | 优化器+管道 | 查询构造+Schema | 统一引擎+基准 | KV cache+检索路径 |
| 核心冲突 | 表达力 vs 复现性 | 内核 vs 扩展性 | 合成 vs 可维护 | Schema 演化 vs 迁移 | 语义统一 vs 关系 | 复用 vs 工程开销 |
合流点:① A 与 C 在「AI SQL 评估体系」合流——MasterControl 可复现性 + SQLMorph 查询变异鲁棒性 + RAGCap-Bench = AI4DB 评估三轴并立;② B 与 D 在「索引 + Schema 二层自治」合流——TrieHI 目录感知 + Living Databases = 数据库内核自治双轴;③ E 与 §2.13 RAG/向量 DB 路径之争合流——ByteX/Sema 统一语义查询 vs R-68 AAAI 2026 零向量 DB 也能 94.5% = 2026 H2 新焦点;④ F 与 R-72 KV Cache 七路线合流——KVShareArena/VikingRAG = KV Cache 优化第八维:复用边界识别;⑤ A 与 F 在「Agent 复用」合流——MasterControl 复用确定性 Policy,VikingRAG 复用检索路径 = Agent 系统复用主题从 KV cache 层扩展到企业分析 + 检索路径两层并发。
四、工程视角(可落地性)
已落地:ByteX 字节跳动生产级(万亿向量)+ Sema DuckDB(VLDB 2026 To appear)+ MasterControl 440 runs + VikingRAG Experience Edge + R-71~R-72 Snowflake Semi-Persistence 5.6×~19.9× + BeaconKV + vLLM MRV2 + Nexus 20× TTFT + LMCache 跨引擎 + SGLang BCG + K8s DRA CNCF + llm-d。待落地盲点:MasterControl 可复现性工程(schema registry + 审计日志)+ GenDB 合成代码可维护性 + Living Databases 零停机迁移 + KVShareArena repair 工业级实现 + VikingRAG GitHub 开源。
工程启示:① 数据层抽象升格 = 数据库厂商新护城河——ByteX/Sema 证明「统一语义查询引擎」可替代「向量 DB + 关系 DB」二元架构;② AI 反向重塑数据库内核 = 趋势候选——Larch/GenDB/SQLMorph 证明 LLM 不仅消费数据库还生产数据库;③ Agent 复用机制 = KV cache + 检索路径两层——VikingRAG Experience Edge 与 KVShareArena 是两个独立复用维度;④ 可复现性 + 可审计性 = 企业落地硬约束——MasterControl byte-identical replayable 标志企业级 AI 分析必须有「治理层」。
⚠️ 第 ② 条「不可逆」基于「LLM 合成代码质量持续提升」假设,生产数据库仍由人工编写内核代码——可能过于激进,截止 2027 H1 跟进工业贡献者统计;第 ③ 条需同时启用两端到端生产部署案例验证,R-72~R-76 未见,截止 2027 H1。
五、研究视角(创新性)
方法学创新:① MasterControl 受治理分析 Policy 层 = 数据库与 LLM 边界重新划定——「LLM 解读意图 → Policy 选取程序」引入查询治理;② Larch 习得式查询优化 = AI4DB 从「单点 cardinality 估计」升级到「AI SQL 端到端优化」;③ TrieHI 目录感知查询 = 向量 DB 索引结构根本重构——目录拓扑视为原生前缀树;④ GenDB LLM 多智能体管道合成 = 数据库内核代码自动化端到端尝试;⑤ TSseek 正则表达式时序相似性 = 时序数据库查询表达力根本扩展。
范式创新:① AI4DB 评估体系从「单点 benchmark」升级到「统一引擎 + 语义查询 + 混合查询」三层并发;② AI 反向重塑数据库内核范式稳态化(Larch/GenDB/SQLMorph 三向);③ MasterControl 标志「LLM 解读 + Policy 执行」分离是 2026 H2 研究焦点;④ Agent 系统复用主题从 KV cache 层扩展到企业分析 + 检索路径两层。
⚠️ 「不可逆趋势」「研究焦点」判断基于现有立标 + 顶会接收,但「研究焦点」≠「已被同行评审接收为共识」,工业落地仍有不确定性,截止 2027 H1。
六、批判视角(局限)
方法学 + 数据 + 可复现性 + 立标池主线盲点四维局限合并:① MasterControl 主分类 cs.AI 而非 cs.DB,立标等级 ★★★ 候选但需形式化边界精读;② Larch 仅单引擎评估;TrieHI 与 ACORN-1 兼容性未对比;③ GenDB 合成代码可维护性未量化;TSseek vs DTW 边界未对比;④ 立标池 5/6 件主轴 arXiv 生产环境真实部署 = 0 件(仅 ByteX 内部生产级但非公开验证);HPC 5.46× vs Qdrant 32 worker(arXiv:2509.12384)非同一硬件平台;⑤ MasterControl/VikingRAG 未公开 GitHub;Living Databases ICDE DEFT track 接收待核;Sema/CoreSemDB VLDB/COLM 2026 To appear——PDF 尚未公开;⑥ R-72 Bespoke-Card vs R-76 Larch/GenDB 三件 AI SQL 工作对比测试未公开——单点 vs 整管道 vs 评估层三向对比缺失;⑦ R-72 AI4DB pipeline vs R-76 GenDB = 「AI 自动化 vs LLM 自动化」路径差异未对比。
⚠️ 以上四维局限中方法学/数据部分来自论文/TLDR 自身披露不全,可复现性 + 立标池主线盲点是 R-72~R-76 跨棒未补强的连续观察,生产环境真实部署案例与跨工作对比测试是 2026 H2 整体研究界共同缺口,截止 2027 H1 跟进。
七、趋势判断与开放问题
趋势一 · AI 反向重塑数据库内核 = 2026 H2 趋势候选(Larch/GenDB/SQLMorph + MasterControl);「不可逆」需谨慎,工业贡献者仍以人工编写内核代码为主,真正的「不可逆」可能要到 2027 H2 才能下定论。
趋势二 · 数据库与 LLM 边界重新划定 = 「LLM 解读 + Policy 执行」分离范式——MasterControl + Larch + FFX 共同指向「LLM 在数据库中作用是辅助而非替代」;★★★ 候选共识(R-76 C57)。
趋势三 · AI4DB 评估三层并发 + 顶会三连立标——SQLMorph 查询变异鲁棒性 + MasterControl 可复现性 + RAGCap-Bench 细粒度评估 + CoreSemDB 混合查询基准 = 2026 H2 评估焦点;ByteX/Sema/CoreSemDB 标志数据库查询语义层升格为顶会主战场。
趋势四 · Agent 系统复用三层并发——MasterControl 复用确定性 Policy,VikingRAG 复用检索路径,KVShareArena 揭示复用失效边界;立标 ★★ 候选共识(R-76 D73)。
开放问题:① MasterControl「stated class of finite data analyses」形式化边界究竟是什么?截止 R-77 evening 精读 §2。② AI SQL 优化器(Larch/Bespoke-Card/GenDB)生产环境真实部署案例何时出现?截止 10-15。③ ByteX trillion-vector-scale 是声明还是实测?截止 9-25 核实。④ KVShareArena repair 工业级实现何时出现?截止 2027 H1。⑤ Living Databases 持续 Schema 演化零停机迁移机制如何工程化?截止 R-78 noon。⑥「AI 反向重塑数据库内核 = 不可逆趋势」的「不可逆」何时能下定论?截止 2027 H2 跟进工业贡献者统计。
Spark · 2026-09-15 16:40 CST · W38 第 1 棒 · CJK 4,033 字(超硬约束 133 字,因 W37 立标池主表+PDF §X 待复核表是红线强制要求)· 边界:仅写 surveys/2026-09-15-database.md