Text2SQL 破局技术解析之二：MQL 实现与复杂性

在基于 "规范文本" 的 NLQ 架构中，MQL（Metrics Query Language）作为规范文本的确定性编译目标，承担着关键使命。本文作为 "规范文本" 篇的延续，将继续解析 MQL 的设计逻辑及其实现机制。

MQL：精确语义的承载者

规范文本作为自然语言形式，仍可能存在语义边界模糊的情况。MQL 的引入，正是为了建立精确的语义基准。

MQL 承担着承上启下的作用。作为规范文本的确定性编译目标，需要建立精确的语义基准，消除自然语言中可能存在的残余歧义。同时通过精心设计的语法结构，在保持对企业级复杂查询足够表达力的前提下，将查询能力限制在合理范围内，确保可控性与准确性。

这种平衡体现在 MQL 的四类查询范式中：单表明细查询、单表汇总查询、多表明细查询、多表汇总查询。这些范式基本覆盖了 BI 场景下的典型查询模式，为从规范文本到精确查询的转换提供了系统的表达框架。

单表明细查询：基础数据筛选

规范文本："订单金额不低于 1 千元的订单"

MQL 实现：

SELECT 订单金额 as 订单金额,订单编码,客户名称,签单日期,发货日期,收货日期 
FROM orders
WHERE 订单金额>=1000

这是最简单的查询范式，基于单一数据源 且不涉及聚合计算。MQL 在此场景中的作用主要体现在：

• 字段精确映射：将"订单金额"、"客户名称"等自然语言词汇准确对应到数据库字段

• 条件准确转换：将"不低于 1 千元"转换为精确的数值比较条件订单金额 >=1000

• 结果集规范：明确指定需要返回的字段集合

此类查询常见于基础数据检索和简单条件过滤，为其他查询提供基础能力支撑。

单表聚合查询：维度聚合分析

规范文本："各城市发货总金额"

MQL 实现：

SELECT orders.sum(订单金额) as 总金额 
ON city as 城市 
FROM orders
BY 发货城市

这里引入了维度 和聚合的概念，体现了 MQL 的核心价值：

• 维度建模：通过 ON city as 城市明确定义分析维度

• 聚合计算：使用 sum(订单金额) 实现指标汇总

• 分组逻辑：BY 发货城市 指定了分组依据字段

此类查询是 BI 分析的基础，MQL 通过清晰的语法结构将业务分析需求转换为准确的数据聚合逻辑。

多表明细查询：关联信息整合

规范文本："订单数大于 5 的客户信息以及总订单金额"

MQL 实现：

SELECT
    客户编码,
    客户名称,
    联系人,
    联系人职务,
    城市编码,
    orders.count(DISTINCT 订单编码) AS 订单数,
    orders.sum(订单金额) AS 总订单金额
FROM
    customer 
JOIN
    orders 
HAVING
    (订单数> 5)

这个例子展现了 MQL 处理复杂数据关系的能力：

• 多表关联：通过 JOIN orders 实现客户表与订单表的关联

• 混合查询 ：在主表明细 基础上挂载子表聚合结果

• 自动关联：基于元数据自动推导 customer 与 orders 间的关联条件

• 结果集过滤：通过 HAVING 对结果集进行过滤

此类查询满足了在主体信息基础上附带相关统计指标的业务需求，体现了 MQL 在复杂场景下的表达能力。

多表汇总查询：多项指标对齐

规范文本："各个类别的订单总数和在线订单数"

MQL 实现：

SELECT orderdetail.count(DISTINCT 订单编码) as 订单总数,
       website_event.sum(在线订单()) as 汇总在线订单数 
ON ProductType as 类别 
FROM orderdetail
BY 产品类别 
JOIN website_event
BY 产品分类

这是更复杂的指标查询范式，展现了 MQL 的高级特性：

• 多源整合：从 orderdetail 和 website_event 两个独立数据源分别计算指标

• 维度对齐：通过 ON ProductType as 类别实现不同来源数据按统一维度对齐

• 复杂指标：在线订单 () 代表可预定义的业务指标计算

此类查询常见于跨主题的综合分析场景，MQL 通过统一的维度模型和指标体系，实现了数据关系的简洁表达。

这四项查询范式能够清晰描述从简单筛选到复杂跨源分析的各类 BI 场景，为自然语言查询提供了较全面的表达能力。同时，MQL 采用类 SQL 的语法设计，具备严谨的规范性，将查询能力进行限制，杜绝过于随意的查询请求，但仍保持了足够的复杂度，在表达力与规范性之间做出了有效平衡。

DQL：透明化表间关联

仔细观察上面的 MQL 语法，多表查询的语句只是处理了聚合后的对齐，SQL 中经常出现的多对一的外键关系并没有出现。比如在订单中引用其客户地址，也就是主查询表是订单表，但要和客户表 JOIN 获取其地址信息。

MQL 可以应对这种外键关联场景吗？如何应对呢？

答案是 MQL 和 SQL 之间还有一个中间层DQL（Dimensional Query Language），一种基于维度的查询语言。DQL 通过 "外键属性化" 特性，巧妙地解决了表间关联的复杂性。我们通过具体实例说明这一机制：

比如用户输入"请帮我查一下北京发往青岛的订单"，首先会由 LLM 转换成标准文本"北京 发往 青岛 订单"，接下来 NLQ 引擎解析后生成 MQL：

SELECT 发货城市 as 发货城市,收货城市 as 收货城市,订单编码,客户名称,签单日期,发货日期,收货日期,订单金额
FROM orders 
WHERE (发货城市=30101) AND (收货城市=20201)

到这一步还只有订单表，不涉及客户表。

然后，这一句 MQL 将会被进一步转换为 DQL：

SELECT shipcity, customerid.citycode,ordered,customerid,signdate,shipdate,receivedate,amount
FROM orders 
WHERE shipcity=30101 and customerid.citycode=20201

这时候还是没有出现客户表，但收货城市被转换成了一个对象形式：customerid.citycode。cutstomerid 是订单表的字段，而 citycode 则是客户表中的字段。

DQL 引擎会再生成可执行的 SQL：

SELECT o.shipcity, c.citycode, o.ordered, o.customerid, o.signdate, o.shipdate, o.receivedate
FROM orders o
JOIN customer c ON o.customerid = c.id
WHERE o.shipcity = 30101 AND c.citycode = 20201

这个最终执行的 SQL 有了显式的 JOIN 子句，关联了 orders 和 customer 两个表。

DQL 仍然基于单表查询，但在获取客户表的收货城市时使用了customerid.citycode，即外键. 外键字段（类似对象. 属性）的方式。这种将多对一的外键关系抽象为对象属性的访问方式称为"外键属性化"，这样无论有多少层表间关联，都可以通过点操作符逐级访问到，而 FROM 后面只有一个单表，这样就巧妙地建立了表间关联，但语法中消除了显式的 JOIN。DQL 之所以可以使用外键属性化，是因为数据之间的关系已经在数据模型层面定义好了，直接使用即可。模型定义很简单，一般技术人员就能完成。

DQL 为 MQL 以单表查询实现多表关联奠定了基础，MQL 中 FROM 子句中的一个单表，在 SQL 并不是单表，它很可能是个关联很多层维表的复杂 JOIN。

SPL：复杂指标计算引擎

尽管 MQL 和 DQL 能够覆盖大部分 BI 查询场景，但在处理复杂业务指标时仍存在局限。诸如股票连涨天数、用户留存率等需要多步计算或特殊算法的场景，SQL 的实现会非常复杂而且难以被嵌入复用，这时候需要引入更专业的计算能力，也就是SPL（Structured Process Language）。

SPL 作为专门处理复杂计算的语言，在架构中扮演着计算引擎的角色：

• 时序计算：支持移动平均、周期对比、连续增长等复杂时间序列分析

• 集合运算：处理分组排名、TopN 分析、集合交并差等操作

• 流程计算：实现漏斗分析、路径挖掘、归因分析等业务场景

• 数学计算：提供统计分布、相关性分析等高级功能

MQL 可以直接使用 SPL 定义的指标，比如要计算大订单数量，大订单是指订单金额超过最大金额 50% 的订单。这时就可以定义 SPL 计算指标：

(x=?1.max(订单金额)/2,?1.count(订单金额>=x))

MQL 碰到用 SPL 定义的指标时，将会先生成读数用的 DQL（再转换成 SQL）执行后再用 SPL 在结果集上继续计算出这些复杂指标。如果 MQL 中没有 SPL 定义的指标，那将会被转换成 DQL 继续解析掉关联生成完整的 SQL 执行。

到这里润乾 NLQ 架构的各个组件均已呈现：

• LLM 保障灵活性：处理自然语言的多样性

• 规范文本确保准确性：通过可确认的中间层解决语义幻觉

• MQL 提供规范性：建立精确的查询语义基准

• DQL 处理数据关联：通过维度建模简化复杂的数据关系

• SPL 实现复杂计算：专业处理高级分析需求

各组件在保持独立性的同时，通过清晰的接口定义实现无缝衔接，形成了一个既灵活又可靠、既强大又可控的解决方案。

润乾 NLQ 通过 MQL、DQL、SPL 的协同设计，构建了一个层次清晰、职责分明的 Text2SQL 架构。MQL 作为规范文本的精确编译目标，在保持足够表达力的同时确保了查询的规范性；DQL 通过维度建模和关联透明化，降低了数据访问的复杂度；SPL 则专注于复杂指标计算，扩展了系统的分析能力。

这种分层架构解决了 "灵活性、准确性、复杂性" 的三难困境，也为企业级 BI 应用提供了可靠的技术基础。在接下来的文章中，我们将继续深入探讨基于词典的 NLQ 引擎如何将规范文档准确地编译成 MQL。