在基于 "规范文本" 的 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。
