查询解析与执行计划上下文和工具如何分工解析器负责把 SQL 变成可验证的语法树。意图识别、敏感字段标注和检索上下文可以建立在 AST 之后但不要塞进词法和语法循环。前者追求确定性与兼容性后者需要超时、降级和审计两者的故障模型不同。边界先定清楚Parser 的输入是 SQL、字符集和会话语法选项输出是 AST、错误位置和必要的元数据。它不访问网络也不根据历史查询改变语法结果。定制语法时应将方言扩展、版本开关和错误码保持在同一层避免语义模块偷偷接受本来不合法的 SQL。语义模块可以读取脱敏后的 AST 摘要、Schema 元数据和显式授权的上下文给出标签或改写建议。建议必须重新走类型、权限和等价性检查超时、缺少上下文或模型不可用时回到未改写 AST。接口和内存生命周期跨模块传递 AST 时先说明所有权。内核使用 arena 或MEM_ROOT时异步任务不能持有请求结束后失效的节点指针。可传递序列化摘要或在明确的生命周期内复制必要节点“零拷贝”只有在所有权和线程模型都满足时才成立。错误也应分层语法错误返回数据库既有错误策略拒绝只记录原因并走原路径内部故障记录诊断信息不把实现细节暴露给客户端。落地顺序先建立解析兼容测试库覆盖项目实际使用的 DDL、查询和边界输入。随后只对只读、语义明确的模板启用标注比较改写前后的结果与计划。最后才考虑自动改写并保持按租户、用户或模板关闭的能力。工具能给出建议解析器不能失去确定性。这条界线守住了后续演进才不会把一次语义故障变成协议故障。