JSqlParser 5.3：一个 SQL 文本与 Java 对象树之间的双向通道

它解决什么问题：把 SQL 变成可编程的树

大多数 Java 项目处理 SQL 时只有两种选择：把 SQL 当作字符串拼接，或者用 JDBC 的 PreparedStatement 参数化。前者容易出错，后者无法应对动态查询结构。JSqlParser 提供第三种方式：把 SQL 文本解析成一个 Java 对象树，每个关键字、表达式、表名都是树上的节点。你可以用访问者模式遍历这棵树，也可以直接调用 getter 方法获取某个具体节点。反过来，你还能用 fluent API 从 Java 对象构建 SQL 文本。这个项目面向的是那些需要分析、改写或生成 SQL 的开发者，比如 SQL 格式化工具、数据脱敏中间件、ORM 框架的底层解析模块。它不负责执行 SQL，也不连接数据库，它只负责 SQL 文本与对象模型之间的转换。

解析机制：从文本到 PlainSelect 再到表达式节点

JSqlParser 的核心是一个基于 JavaCC 生成的解析器。README 中的例子展示了基本流程：调用 CCJSqlParserUtil.parse 方法，传入 SQL 字符串，返回一个 Statement 对象。对于 SELECT 语句，实际类型是 PlainSelect。你可以从 PlainSelect 中取出 selectItems、fromItem 和 where 表达式。每个表达式又是一个独立的类，比如 EqualsTo 代表等号比较，它的左操作数和右操作数分别是两个 Column 对象。这种设计让 SQL 的每个部分都有对应的 Java 类，类型安全。访问者模式是官方推荐的遍历方式，你可以在不修改节点类的情况下，为不同的遍历目的编写不同的访问器。这种机制的好处是，你不需要手写正则表达式或字符串分割来解析 SQL，解析器已经帮你处理了语法细节。

安装与坐标：上游与 Manticore 构建的岔路

安装方式直接决定你拿到的是哪个版本的代码。README 明确建议使用 Manticore 构建，坐标是 com.manticore-projects.jsqlformatter:jsqlparser，版本号用 [5.3.218,) 表示范围，Gradle 里则直接写加号。而传统的上游坐标 com.github.jsqlparser:jsqlparser 对应的是 5.3 版本。README 说上游发布在 Maven Central 上相当旧，而 Manticore 构建是持续发布的，包含最新的性能优化和语法支持。如果你用的是 Maven，需要选择其中一个坐标加入 pom.xml。如果你用的是 Gradle，implementation("com.manticore-projects.jsqlformatter:jsqlparser:+") 会拉取最新版本。这个选择会影响你后续获得的语法更新和 bug 修复，值得在项目初期就定下来。

性能声明：11 倍提升，但需要自己验证

README 给出了一个引人注目的性能对比：最新版解析 SQL 语句平均耗时 7.6 毫秒，而 5.3 版本需要 84.7 毫秒，声称快了 11 倍。它还宣称在真实世界 SQL 上比其他语言的解析器都快，比 sqlglot[c] 快 19 倍。这些数字来自 manticore-projects 的 jsqlparser-bench 项目。但要注意，这些基准是项目自己发布的，没有独立的第三方验证。如果你是做性能敏感的工具，比如在线的 SQL 审计或防火墙，应该在自己的数据集上跑一遍基准，而不是直接相信 README 里的数字。另外，性能提升可能以牺牲某些语法兼容性为代价，你需要测试自己实际使用的 SQL 方言。

语法覆盖：十二种方言，一个语法文件

JSqlParser 声称用一个语法覆盖所有主流 RDBMS，包括 BigQuery、Snowflake、DuckDB、Oracle、MySQL、PostgreSQL 等十二种方言。这意味着你不需要为每种数据库切换不同的解析器。它支持常见的 DML 和 DDL 语句，比如 SELECT、INSERT、UPDATE、MERGE、DELETE、CREATE、ALTER、DROP。还包括一些特殊语法：PostgreSQL 的行级安全策略（CREATE POLICY、ROW LEVEL SECURITY），Salesforce 的 SOQL 中的 INCLUDES 和 EXCLUDES。嵌套子查询、绑定参数（? 和 :name）、窗口函数、Oracle hint 都在支持范围内。README 还提到 T-SQL 中方括号与数组字面量的歧义处理。这种广度是 JSqlParser 的主要卖点，但也是维护负担。语法是按需添加的，如果你需要某个冷门方言的特殊语法，可能得自己提 issue 或等待社区实现。

Piped SQL：实验性支持，别指望生产环境直接用

Piped SQL 是一种把查询按执行顺序书写的语法，来自 Google 的 BigQuery pipe syntax 和 DuckDB 的 FROM-first 语法。JSqlParser 正在逐步支持这种写法。README 给出了一个例子，用 |> 符号把 WHERE、AGGREGATE、ORDER BY 串联起来。这种语法在传统 SQL 中不存在，所以解析器需要额外处理。目前的支持状态是「progressing」，不是完整实现。如果你要解析的 SQL 大量使用 Piped SQL，建议先检查你需要的具体语法是否已经支持。对于大多数传统 SQL 项目，这个功能可以暂时忽略。

Java 版本要求：JDK 8 用户被挡在 5.x 之外

版本与 Java 运行时的对应关系很明确：4.9 是最后一个支持 JDK 8 的版本，5.0 开始要求 JDK 11 运行时，并且 AST Visitor 有破坏性变更。5.1 之后构建需要 JDK 17 工具链，5.4 之后解析器改用 JavaCC 8 生成。这意味着如果你还在用 JDK 8，你只能停留在 4.9，无法获得后续的语法和性能更新。如果你的项目已经迁移到 JDK 11 或更高，那么 5.3 是可用的。但要注意，5.0 的 Visitor 变更可能影响你现有的遍历代码，升级时需要参考迁移指南。这个版本约束是硬性的，没有绕过办法。

替代方案：JOOQ 的手写解析器，不同的设计哲学

README 提到了 JOOQ 作为替代。JOOQ 的 SQL 解析器是手写的，而 JSqlParser 是用 JavaCC 生成的。这是一个根本性的差异：手写解析器通常能更好地处理语法歧义，因为作者可以针对特定上下文编写专门的逻辑；生成解析器则依赖语法文件的规则，遇到冲突时需要调整文法。JOOQ 是双重许可证（商业和开源），而 JSqlParser 是 Apache-2.0，对于商业闭源项目，JSqlParser 的许可证更宽松。JOOQ 还提供 SQL 转换和 JDBC 支持，但那是另一个层面的功能。如果你只需要纯粹的解析和 AST 操作，JSqlParser 更轻量；如果你需要完整的 SQL 构建和数据库交互，JOOQ 可能更合适。选择时还要考虑团队对 JavaCC 语法的熟悉程度，因为修改 JSqlParser 的语法需要理解 JavaCC 的规则。

编辑结论

JSqlParser 适合需要在 JVM 内解析、改写或生成 SQL 的开发者，尤其是那些要处理多种数据库方言、需要细粒度 AST 操作的工具类项目。若你的项目仍停留在 JDK 8，则只能使用 4.9 版本，5.x 系列要求 JDK 11 运行时和 JDK 17 构建工具链。若你追求极致解析速度，可以关注 5.3 之后的 Manticore 构建，但要注意它发布在 com.manticore-projects.jsqlformatter 坐标下，与上游 com.github.jsqlparser 的版本号并不完全同步。在采用前，应先确认你需要的 SQL 特性（如 Piped SQL 的完成度）在你的目标版本中是否已实现，并检查 AST Visitor 的破坏性变更是否影响现有代码。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes