发布时间：2025 年 04 月 01 日
代码编写
CrackSQL——首个结合规则与 LLM 方法的混合 SQL 方言翻译系统，借助 LLMs 的适应性，大幅减少人工干预，同时通过基于功能的查询处理，将长复杂 SQL 分割处理，从而提升翻译准确性。为增强系统鲁棒性，CrackSQL 采用了新型跨方言语法嵌入模型，实现精准语法对齐，并引入自适应局部到全局翻译策略，有效解决相互依赖的查询操作。CrackSQL 支持三种翻译模式，并提供多样化的部署和访问选项，包括 Web 控制台界面、PyPI 软件包以及命令行工具，助力其在各类现实场景中的广泛应用。
添加请注明Text2SQL
如遇无法添加，请+ vx: iamxxn886
一、为什么需要 SQL 方言翻译技术？
1.1 数据库系统的多样性
在现代数据管理中，SQL（Structured Query Language，结构化查询语言）是访问和操作数据库的核心工具。然而，尽管所有主流数据库系统（如 PostgreSQL、MySQL、Oracle 等）都支持 SQL，它们的语法和功能却存在显著差异。例如，PostgreSQL 中的
ARRAY
类型在 MySQL 中并不直接支持，而 Oracle 的
ROWNUM
关键字在其他数据库中也没有对应实现。这种差异使得在不同数据库之间迁移或共享 SQL 查询变得复杂，开发者需要针对每个数据库系统重新编写或调整 SQL 语句。
1.2 现有方法的局限性
目前，SQL 方言翻译主要依赖三种方法，但每种方法都有其局限性：
人工翻译 ：依赖专家手动改写 SQL，虽然准确性较高，但效率低且容易出错。例如，将一个包含复杂窗口函数的 PostgreSQL 查询迁移到 MySQL 可能需要数小时的手动调整。
规则系统 ：如 SQLGlot，通过预定义规则进行翻译。这种方法虽然自动化程度较高，但维护成本高，难以覆盖所有复杂场景。例如，SQLGlot 在处理嵌套子查询时可能无法正确识别某些语法结构。
大语言模型（LLM，Large Language Model）
：如 GPT-4，虽然能够自动生成 SQL 翻译，但容易产生“幻觉”（生成不存在的函数或语法）。例如，GPT-4 可能会将 PostgreSQL 的
JSONB
类型翻译为 MySQL 中不存在的
JSONB
函数。
1.3 CrackSQL 的诞生
为了解决上述问题，CrackSQL 应运而生。它结合了规则系统和 LLM 的优势，既能减少人工干预，又能提高翻译准确性。例如，CrackSQL 通过功能分解将复杂查询拆分为多个简单操作，再分别进行翻译，从而避免了 LLM 在处理长查询时的“幻觉”问题。此外，CrackSQL 还引入了跨方言语法嵌入模型，能够精确匹配不同数据库中的等效语法元素，进一步提升了翻译的鲁棒性。
通过这种混合方法，CrackSQL 成为首个能够高效、准确地进行 SQL 方言翻译的系统，为数据库迁移和跨数据库分析提供了强有力的支持。
- CrackSQL 的核心技术是什么？
2.1 技术架构
如上图所示，CrackSQL包含四个模块以实现跨方言SQL翻译。支持三种运行模式（见下表），可灵活处理用户请求。通过将基于规则的方法与大语言模型（LLM）相结合，CrackSQL在保持与传统数据库操作兼容性的同时，确保了强大的跨方言互操作性。
工作流程：
- • ❶翻译过程始于用户通过三种方式（网页控制台、PyPI软件包和命令行终端）提交翻译请求至用户界面。随后，这些请求被路由至统一翻译服务器，该服务器通过SQLAlchemy引擎协调核心翻译逻辑。
- • ❷服务器根据用户指定参数动态配置翻译流程，不同运行模式需调用不同服务模块。以"规则+LLM"模式为例，其翻译步骤如下：首先进行基于功能的查询处理，将完整SQL分解为多个片段以便LLM处理长SQL语句；随后在数据库引擎指导下采用由局部到全局的翻译策略，定位存在执行错误的SQL片段。
- • ❸翻译过程中，系统会通过多轮迭代与计算引擎交互，执行两项基本操作：(1) 对错误片段实施基于规则工具与LLM的混合翻译；(2) 基于新设计的嵌入模型进行跨方言语法匹配，通过相关方言规范（如等效函数的使用说明）增强LLM上下文理解。
- • ❹翻译完成的SQL片段返回至服务器。
- • ❺交由数据库引擎检测剩余执行错误。
- • ❻若验证无误，最终译文将被传递至用户界面。
2.2 功能化查询处理
CrackSQL 的核心技术之一是
功能化查询处理
。它将复杂的 SQL 查询分解为多个小功能模块，例如将
TIMESTAMP DIFF()
函数单独处理。这种“分而治之”的策略大大降低了 LLM（Large Language Model，大语言模型）的翻译难度，减少了“幻觉”问题。举个简单的例子，如果你有一个复杂的 SQL 查询，CrackSQL 会先把它拆解成多个小部分，比如日期计算、条件筛选等，然后分别处理这些部分，最后再整合成一个完整的查询。这种方法不仅提高了翻译的准确性，还让 LLM 更容易理解每个小模块的功能。
2.2 跨方言语法匹配
CrackSQL 引入了
跨方言嵌入模型
，通过对比不同方言的语法结构和文本描述，找到功能等效的语法元素。例如，PostgreSQL 中的
ILIKE
可以匹配为 MySQL 中的
LIKE
。这个模型的核心在于它能够理解不同数据库方言之间的细微差别，并自动找到最合适的翻译方式。比如，如果你从 PostgreSQL 迁移到 MySQL，CrackSQL 会自动识别并转换那些在 MySQL 中不支持的语法，确保查询的功能不受影响。
2.3 局部到全局的翻译策略
CrackSQL 采用了 渐进式翻译策略 ，先翻译局部功能模块，再逐步扩展到整个查询。这种策略有效解决了查询操作之间的依赖关系，确保翻译结果的准确性。举个例子，如果你有一个包含多个子查询的复杂 SQL 语句，CrackSQL 会先翻译最内层的子查询，确保它的语法正确，然后再逐步向外扩展，最终完成整个查询的翻译。这种方法避免了传统翻译工具在处理复杂查询时容易出现的错误。
2.4 开源与部署
CrackSQL 已经开源，代码和文档可以在 https://github.com/weAIDB/CrackSQL 上获取。此外，它还提供了 Web 控制台、PyPI 包和命令行工具，方便用户灵活使用。无论你是开发者还是数据分析师，都可以根据自己的需求选择合适的部署方式。比如，你可以通过 Web 控制台快速测试 SQL 翻译，也可以通过命令行工具集成到自动化脚本中，极大地提高了使用的灵活性。
三、CrackSQL 的实际效果如何？
3.1 实验设置
CrackSQL 在真实的 SQL 查询数据集上进行了测试，重点评估了从 Oracle 到 MySQL 和 PostgreSQL 的翻译效果。实验使用了修改版的 BIRD 基准测试，涵盖了多种复杂的 SQL 查询场景，以确保测试的全面性和代表性。
3.2 实验结果
- 错误率显著降低
CrackSQL 在 95%的测试案例中实现了零错误，尤其在语法规则、函数映射和数据类型匹配方面表现优异。例如，在将 Oracle 的日期函数转换为 MySQL 时，CrackSQL 能够准确识别并映射等效函数，避免了传统规则系统中常见的错误。
- 规则系统的局限性
传统规则系统（如 SQLGlot）在不同翻译场景中表现不一致。例如，SQLGlot 在将 Oracle 的某些关键字转换为 PostgreSQL 时，可能会出现关键字误用或遗漏的情况。而 CrackSQL 通过跨方言嵌入模型（Cross-Dialect Embedding Model）实现了更稳定的准确性，能够自动适应不同方言的语法规则。
- LLM 的“幻觉”问题
直接使用 GPT-4 翻译时，错误率较高，尤其是列名重命名和数据类型错误。例如，GPT-4 可能会将 Oracle 的
NUMBER
类型错误地转换为 MySQL 的
INT
类型。CrackSQL 通过混合验证机制（Hybrid Validation Mechanism）有效避免了这些问题，确保翻译结果的准确性和一致性。
3.3 用户友好性
CrackSQL 提供了直观的 Web 控制台，用户可以实时查看翻译过程和结果。例如，用户可以在 Web 界面上输入 SQL 查询，选择目标数据库，并立即看到翻译后的 SQL 语句。此外，CrackSQL 还支持 Python 包和命令行工具，满足不同场景的需求。例如，开发者可以通过 PyPI 安装 CrackSQL 包，并在 Python 脚本中调用其翻译功能，实现自动化 SQL 翻译。
通过以上实验和用户反馈，CrackSQL 在 SQL 方言翻译领域展现了显著的优越性，不仅提高了翻译的准确性，还提升了用户的使用体验。
- • 论文原文: https://arxiv.org/abs/2504.00882
- • 获取更多最新 Arxiv 论文更新: https://github.com/HuggingAGI/HuggingArxiv!
- • 加入社群，+v: iamxxn886
- • 点击公众号菜单加入讨论