将基于Archery的web数据库审计查询平台封装为jdbc接口的可行性研究（基于AI）

【SQL 审核查询平台】Archery使用介绍

https://cloud.tencent.com/developer/article/2371101

背景：

1、已抽取基本的web接口为dbplus-api-starter这个spring starter项目；

2、已有基于此的一个现成的成熟的应用dbplus-mcp（不支持DDL和DML，查询默认有Limit限制防止查询数据量过大让服务崩掉）

结合dbplus-mcp和依赖的dbplus-api-starter这个spring starter项目，分析我这个基于web接口登录认证进行数据库查询（包括获取数据库

元数据），基于这些逻辑，封装为一个基于配置的jdbc接口可以让java程序使用通用jdbc连接字符串和驱动程序，来进行数据库操作的可行性

方案，参考 大数据 将 json或者异构数据源 数据 封装为 标准jdbc接口，一些技术实现方案

这种方案，分析技术实现可行性和思路

核心链路已经看清了，我整理成几种可落地架构，并评估边界与风险。

• Updated Plan

└ ✔ 梳理现有项目结构

✔ 定位查询认证链路

✔ 提炼 JDBC 封装方案

✔ 评估可行性与风险

• 我先按 brainstorming 的思路看了现状，结论是：这个方案技术上可行，但建议先做"只读 JDBC 驱动 / JDBC 网关"，不要一开始就追求完整

数据库协议兼容。

现状判断

• 你现在已经具备了 JDBC 封装最关键的三层能力：认证会话、元数据访问、SQL 查询执行。

• 认证层已经比较完整：DbPlusAuthManager#getAuthResult 做了 TTL 缓存和定时刷新，见 dbplus-api-starter/src/main/java/org/

mydbplus/api/auth/DbPlusAuthManager.java:36。

• 登录层已经处理了 IAM 跳转、lt/execution、RSA 密码、公私钥、csrftoken/sessionid 提取，见 dbplus-api-starter/src/main/java/

org/mydbplus/api/auth/IamPreAuthClient.java:42。

• 请求头注入层已经统一封装了 Cookie 和 X-CSRFToken，见 dbplus-api-starter/src/main/java/org/mydbplus/api/http/

DbPlusHeadersProvider.java:21。

• 元数据接口已经有实例、库、表、表结构四个关键入口，见 dbplus-api-starter/src/main/java/org/mydbplus/api/

DbPlusApiClient.java:216、dbplus-api-starter/src/main/java/org/mydbplus/api/DbPlusApiClient.java:229、dbplus-api-starter/

src/main/java/org/mydbplus/api/DbPlusApiClient.java:249、dbplus-api-starter/src/main/java/org/mydbplus/api/

DbPlusApiClient.java:262。

• 查询层已经能把远端结果转成"列名 + 列类型 + 行数据"，这本质上已经很接近 JDBC 的 ResultSet 语义，见 dbplus-api-starter/src/

main/java/org/mydbplus/api/query/DbPlusQueryExecutor.java:72。

• dbquery-jdbc-mcp 里已经有一套标准 JDBC 元数据访问样板，可直接借鉴接口形状和返回结构，见 dbquery-jdbc-mcp/src/main/java/org/

dbquery/service/MysqlJdbcClient.java:13、dbquery-jdbc-mcp/src/main/java/org/dbquery/service/MysqlInspectService.java:40。

可行性结论

• 只读查询 + 元数据 JDBC 化：高可行。

• 让 Java 程序用 DriverManager.getConnection(...) 接入：高可行。

• 兼容大多数内部工具/报表程序：中高可行。

• 完整支持事务、批量写入、预编译、数据库锁语义：低可行。

• 伪装成"现成 MySQL 驱动"让所有工具零改造直连：可行但成本很高。

为什么可行

• JDBC 的最小闭环其实就是：Driver → Connection → Statement → ResultSet → DatabaseMetaData。

• 你现有 starter 已经提供了远端会话、元数据、查询结果结构化，差的不是"能力"，而是 JDBC 接口适配层。

• 从技术本质看，这和"大数据把 JSON/REST/异构数据源封成 JDBC"是同一类问题：把非 JDBC 后端映射成 JDBC 抽象，核心是 schema-on-

read、类型映射、SQL 能力边界、分页/游标和元数据补齐。

推荐的 3 种实现路线

• 方案 A：自定义 JDBC Driver 直连 dbplus Web 接口

最直接。驱动内部复用 dbplus-api-starter 的认证和查询逻辑，实现 org.mydbplus.jdbc.DbPlusDriver。适合内部 Java 项目接入，开发

成本最低。

• 方案 B：JDBC Driver + 中间网关服务

驱动不直接登录 dbplus，而是连你自己的网关；网关再复用 starter 或 MCP 调 dbplus。适合统一鉴权、审计、限流、缓存、多租户治

理。我更推荐这个作为中期方案。

• 方案 C：基于 Calcite / Avatica / 查询虚拟化引擎

如果目标不只是 dbplus，而是以后还要接 JSON、HTTP API、ES、文件、异构库，应该走这一类"查询虚拟化"路线。最强，但也最重。

我对你当前场景的建议

• 短期推荐：A 的实现方式，B 的架构边界。

• 具体说就是：先把 dbplus-api-starter 抽成一个不依赖 Spring 的 dbplus-api-core，然后做 dbplus-jdbc-driver；如果后面要共享认

证、治理和缓存，再加 dbplus-jdbc-gateway。

• 不建议 JDBC driver 直接依赖 dbplus-mcp，因为 MCP 更适合 AI/tool calling，不是 JDBC 协议的天然后端；它可以当参考，不适合做最

终 JDBC 内核。

建议的目标形态

• 驱动类：org.mydbplus.jdbc.DbPlusDriver

• URL 形态：jdbc:dbplus://local?host=https://xxx&instance=xxx&database=xxx&dbType=mysql

• 连接属性：user、password、encryptedPassword、publicKey、authTtlMinutes、fetchSize、queryTimeout、metadataCacheSeconds

• 初期只支持：createStatement()、executeQuery()、getMetaData()

• 初期明确不支持：executeUpdate()、事务提交/回滚、批处理、存储过程、服务端 prepared statement；统一抛

SQLFeatureNotSupportedException

JDBC 抽象怎么映射到你现有模型

• 我建议定义：catalog = instanceName，schema = dbName，table = tableName

• 这样能保留 dbplus 的"实例 → 数据库 → 表"层级，比把 dbName 直接塞进 catalog 更稳。

• 当前代码里 DbPlusDbInfo.instanceName 被复用了 dbName 语义，这在 JDBC 化之前最好先纠正，见 dbplus-mcp/src/main/java/org/

mydbplus/mcp/DbPlusMcpTools.java:67 和 dbplus-mcp/src/main/java/org/mydbplus/mcp/DbPlusMcpTools.java:69。

核心技术实现思路

• Driver：负责解析 JDBC URL 和 properties，注册到 DriverManager

• Connection：内部持有 DbPlusSession，懒加载认证，暴露 getMetaData、createStatement

• Statement：把 SQL 发到 DbPlusQueryExecutor，做超时、fetchSize、maxRows 控制

• ResultSet：把远端 rows + columnTypes 包装成游标

• ResultSetMetaData：由 column_list + column_type 生成 JDBC 列定义

• DatabaseMetaData：调用你现有的 listInstances/listDatabases/listTables/getTableSchema

• TypeMapper：把 varchar、bigint、decimal(10,2)、datetime、json 映射到 java.sql.Types

• CapabilityMatrix：声明支持哪些 JDBC 特性，避免客户端误判

和"大数据把 JSON/异构数据封成 JDBC"一致的关键点

• 逻辑模式层：把异构后端抽成 catalog/schema/table

• 类型系统映射：字符串/数字/时间/JSON/二进制映射到 JDBC 类型

• SQL 能力边界：不是所有 SQL 都支持，必须做能力声明和必要改写

• 下推与回退：能下推到后端的尽量下推，不能下推的在驱动/网关层补

• 分页与流式读取：这是 JDBC 化是否实用的关键，不只是能"查出来"

• 元数据完整性：BI 工具非常依赖 DatabaseMetaData

你当前代码里的关键风险

• dbplus-mcp 里的 query_sql 现在是先全量查回，再做内存分页，见 dbplus-mcp/src/main/java/org/mydbplus/mcp/

DbPlusMcpTools.java:72；这对 JDBC 是危险的，大结果集会内存爆。

• DbPlusQueryExecutor 调 /query/ 时 limit_num=0，见 dbplus-api-starter/src/main/java/org/mydbplus/api/query/

DbPlusQueryExecutor.java:81；如果后端没有真正流式能力，JDBC 的 fetchSize 很难做真分页。

• 你 README 写了 metadata cache / allowlist，但当前 Solon 配置里其实还是注释态，见 dbplus-mcp/src/main/java/org/mydbplus/mcp/

DbPlusApiSolonConfiguration.java:29；所以治理能力不能直接假设"已经有"。

• 当前 SQL 校验依赖 /slowquery/optimize_sqladvisor/，见 dbplus-api-starter/src/main/java/org/mydbplus/api/query/

DbPlusQueryExecutor.java:45；这可能会拦截掉一些 BI 工具自动生成 SQL。

• JDBC 的 DatabaseMetaData 需要比现在更多的元数据：主键、索引、外键、注释、类型信息；这些可能要补接口，或通过

information_schema 查询拼出来。

对"写操作 JDBC 化"的判断

• 查询型 JDBC：适合。

• 元数据 JDBC：适合。

• DML/DDL JDBC：不建议先做。

• 因为你当前平台实际上有审批/工作流语义，比如提单、审批、执行，见 dbplus-api-starter/src/main/java/org/mydbplus/api/

DbPlusApiClient.java:118；这和 JDBC 的 executeUpdate + autocommit/rollback 心智模型并不一致。

最合理的 MVP 边界

• 支持：SELECT、SHOW、DESC、表结构浏览、库表枚举

• 不支持：事务、写入、批量、存储过程、游标更新

• 目标用户：Java 程序、内部工具、报表工具

• 目标定位：只读虚拟数据源驱动

如果你想兼容"通用现成驱动"

• 如果你的意思是"让 Java 用 JDBC 标准方式接入"，那做自定义 Driver 就够了。

• 如果你的意思是"继续用 com.mysql.cj.jdbc.Driver 之类现成驱动也能连"，那就不是 JDBC Driver 问题，而是要做 MySQL/PostgreSQL

wire protocol 代理服务器，复杂度会比自定义 JDBC driver 高一个数量级。

我建议的落地顺序

• 第 1 步：把 starter 提炼成 dbplus-api-core

• 第 2 步：先做只读 JDBC driver

• 第 3 步：补 DatabaseMetaData 与 TypeMapper

• 第 4 步：补服务端分页/游标/导出式大结果集

• 第 5 步：再决定要不要上网关模式或 Calcite 路线

如果你愿意，我下一步可以继续帮你输出一版更具体的 JDBC 驱动模块设计图 + 类清单 + URL/接口草案。