夜雨聆风作者按：在深入分析Together AI的实践后，我发现了五个被绝大部分讨论者忽略的关键洞察——这些问题不解决，所谓的"AI优化数据库"就只能停留在PPT层面。
一、重新审视核心问题：传统优化器困境的根源
所有人都在说"传统CBO（查询优化引擎）优化器有瓶颈"，但很少有人追问：这个瓶颈的本质是什么？
传统优化器的三大问题——统计信息滞后、成本模型不准、规则爆炸——表面上是技术问题，深层是范式局限。CBO优化器本质上是基于相关性」的统计机器，它回答的是"根据历史数据，这种情况下这个计划表现如何"。但查询优化是一个因果决策问题，需要回答的是"因为A，所以选择B"。
这个根本性的范式错位，才是一切问题的根源。
二、我们需要考虑的五个深度洞察
洞察1：语义缓存的"平面陷阱"——二维相似性远远不够
当前所有AI查询优化方案都在谈"语义向量相似度匹配"来复用历史执行计划。但这里有一个致命假设：相似查询=相似计划。
这个假设在实践中屡屡失效。考虑以下场景：
查询A和查询B语义相似度0.95，但B多了一个OR条件，导致HashJoin比NestedLoop慢10倍 查询C和D语义完全相同，但执行时系统内存压力不同，最优计划完全不同 查询E在上午11点执行最优计划A，在下午3点执行最优计划B（数据热力图变化）
很多人没有考虑到的方案：Query Context Tensor（查询上下文张量）
不要只存储查询语义向量，而是构建一个多维执行上下文张量：
Query_Embedding (768维) + Data_Distribution_Vector (64维) +
System_State_Vector (32维) + Time_Series_Context (16维)
= Query_Context_Tensor (880维)
这个张量捕捉的是"在当前系统状态下，这个查询应该用什么计划"，而不是"这个查询长什么样，应该用什么计划"。
洞察2：相关性优化 vs 因果优化——一个被忽视的范式革命
99%的AI查询优化研究都基于相关性模型：收集大量(query, plan, latency)样本，训练一个模型预测最优计划。这本质上是让模型学习"历史上类似的查询用了什么计划"。
但问题是：历史上最优的计划，未来一定最优吗？
因果推断告诉我们，相关性模型会在数据分布偏移时彻底失效。当数据分布发生变化（数据倾斜、新增索引、硬件升级），模型预测会急剧变差。
很多人没有考虑到的方案：Causal Query Optimizer（因果查询优化器）
构建因果图的查询优化器：
将查询计划建模为因果图节点，边表示数据依赖关系 利用do-calculus推断"如果强制使用某个算子，结果会如何变化" 通过反事实推理回答："如果没有选择HashJoin而是MergeJoin，延迟会是多少？" 关键创新：将因果干预纳入强化学习的奖励函数，而非仅仅依赖观察数据
这不是更复杂的ML模型，而是完全不同的决策范式。
洞察3：编译层的"最后一公里"黑洞——AI计划的执行鸿沟
几乎所有讨论AI查询优化的文章都忽略了一个关键问题：AI生成的查询计划，真的能原封不动地执行吗？
现代数据库引擎（ClickHouse、Databricks、Polars）大量使用代码生成（CodeGen）和向量化执行。查询计划被编译成LLVM IR或JIT编译字节码。在这个过程中：
AI生成的计划可能被重新优化 编译器的优化传递可能改变算子顺序 投机执行（Speculative Execution）可能引入计划外的并行性
这意味着训练时观察到的plan-performance映射，在推理时可能完全不同。
很多人没有考虑到的方案：Execution-Aware Plan Representation（执行感知计划表示）
在计划表示中加入编译器约束元数据，描述哪些优化是"可移动的"，哪些是"必须保留的" 建立计划保真度指标：衡量AI计划的意图在编译后保留了多少 在训练数据中标注编译后执行轨迹而非计划生成时刻的状态 使用可微分查询引擎（Differentiable Query Engine）端到端优化，从SQL到硬件指令全程可微
洞察4：多智能体查询优化——被低估的系统架构
当前AI查询优化方案都采用单一模型：输入查询，输出计划。但一个复杂的OLAP查询涉及几十个决策点（Join顺序、索引选择、并行度、分区策略、物化视图选择...），让一个模型同时做所有决策是低效的。
很多人没有考虑到的方案：Multi-Agent Query Orchestration（多智能体查询编排）
构建一个查询优化的"内阁制"：
Join-Agent：专门负责Join顺序优化 Index-Agent：负责索引选择和物化视图决策 Parallelism-Agent：负责并行度和资源分配 Memory-Agent：负责内存管理和数据分片 Meta-Agent：整合各Agent建议，做出最终决策
每个Agent可以是小型专有模型，比单一通用模型更高效、更可解释。Meta-Agent使用辩论（Debate）或共识（Consensus）机制决定最终计划。系统可以类比为"有人擅长关系代数的数学证明，有人擅长系统性能的实际测量，委员会比个人更可靠"。
洞察5：零样本泛化的终极挑战——新Schema来了怎么办？
所有当前方案都依赖在目标数据库上积累足够的(query, plan, performance)训练数据。但当Schema发生变化（新增表、调整分区键、导入新数据源），模型需要重新训练或至少微调。
在生产环境中，这意味着：每次Schema变更 -> 模型重新训练 -> 上线验证 -> 回滚风险。这个成本是不可接受的。
很多人没有考虑到的方案：Schema-Agnostic Meta-Optimizer（元优化器）
核心思路是让优化器学习"如何优化"而非"优化什么"：
将Schema编码为异构图（节点=表/列/索引，边=外键/依赖/覆盖关系） 使用GNN（图神经网络）学习Schema结构与最优计划之间的映射 训练目标是"给定任意Schema图，预测最优计划的结构模式"，而非"给定特定查询，预测特定计划" 关键创新：引入"计划模板"的层级抽象，从具体的(TableA JOIN TableB)泛化到(N小表 JOIN N大表)，使模型具备跨Schema泛化能力
三、Together AI的实践验证了什么？
Together AI的方案验证了三个关键假设：
1. AI取代规则而非辅助规则是可行的
端到端用神经网络替代启发式决策，在特定场景下确实优于传统CBO。关键是训练数据质量和执行上下文捕获。
2. 语义缓存的价值被严重低估
他们发现"查询相似度缓存"是延迟下降52%的主要原因之一。但这个缓存必须基于多维上下文，而非单纯语义相似度。
3. 推理开销可控
通过模型量化和特征缓存，每查询额外开销小于0.5ms是可以做到的。但这是在中等复杂度查询下测量的，超级复杂查询可能不同。
四、落地路径：企业如何分阶段采用
阶段1（0-3个月）：观察者模式
在数据库前端部署代理层，AI优化器和传统优化器并行运行，记录分歧案例。不修改任何实际执行计划，纯粹积累训练数据。
阶段2（3-6个月）：影子模式
对AI优化器的计划进行"影子执行"——在实际返回结果的同时，用AI计划在后台跑一遍但不返回给用户。对比两者的实际延迟差异。
阶段3（6-12个月）：金丝雀发布
对5%的查询启用AI优化计划，监控P99延迟、错误率等指标。设立自动回滚阈值。
阶段4（12个月+）：全面推广
根据行业和查询类型逐步扩大范围，积累足够的置信度后全面替换。
五、未来的五个技术方向
多模态查询理解：融合自然语言查询、图查询、时间序列查询到统一表示 跨引擎通用优化器：构建可对接Spark、Flink、ClickHouse的中间表示层 自治数据库闭环：查询优化与索引推荐、分区调整、配置调优形成完整闭环 隐私保护联邦学习：跨租户学习查询模式而不共享原始数据 可解释性增强：不仅给出最优计划，还要解释"为什么这个计划最优"
结语：AI优化的本质是决策范式的升级
回到最初的问题：Together AI的实践给架构师什么启示？
不是"加AI贴片"，不是"用LLM写SQL"，而是从相关性决策升级到因果性决策，从单点优化升级到系统协同，从静态规则升级到动态适应。
查询优化的终极目标不是找到"最优计划"，而是找到"在当前系统状态下最合适的计划"。这需要AI，但更需要我们对AI的局限性有清醒认知。
真正的架构挑战不是"AI能做什么"，而是"在什么条件下AI做的是对的"。
这才是人类需要持续思考的问题。
本文观点基于对Together AI技术实践的深度分析，部分方案属于原创性思考，供从业者参考探讨。
