如果说SQL审核/SQL优化工具的上半场比拼的是 “支持多少数据库、覆盖多少规则”,那么进入 2025 年,下半场的关键正在发生变化:
谁能在复杂、多数据库、批量化的真实业务 SQL 中,稳定、准确、可扩展地工作。
2025 年 11 月,PawSQL 的一系列更新,正是围绕这一核心命题展开。本文将从数据库支持、SQL 语义建模、性能与审核引擎、工程稳定性四个维度,系统梳理本月的关键进展。
一、多数据库支持:从“能连上”,到“能用好”
✅ TDSQL PostgreSQL:集中式 + 分布式全面支持
11 月,PawSQL 在 国产 PostgreSQL 生态迈出了关键一步:
-
新增 TDSQL PostgreSQL(集中式 / 分布式)完整支持
-
增加 PostgreSQL 版本检测能力,优化慢查询分析路径
-
修正连接信息、驱动标识符与产品文档中的不一致问题
意味着什么?这不再是“语法能过”,而是具备了可用于真实生产审计与性能分析的 PostgreSQL 能力,对金融、政企等国产数据库用户尤为关键。
二、SQL 解析能力:开始“理解脚本,而不仅是语句”
1️⃣ 变量体系重构:为真实 SQL 脚本场景而生
11 月最“隐蔽”、但也最关键的一项工作,是变量解析体系的整体升级:
-
✅ 支持变量赋值并纳入语义模型(model / source writer)
-
✅ 明确变量数据类型,避免后续分析歧义
-
✅ 将变量解析从“语法阶段”前移到 验证阶段
-
✅ MSSQL 支持
DECLARE / SET等本地变量 -
✅ 若外层存在赋值操作,查询折叠(Query Folding)自动放弃,保证语义正确
这解决了什么问题?
在真实业务中,大量 SQL 并不是“单条 SELECT”,而是:
-
含变量
-
多语句
-
脚本化执行
这是很多审核工具长期不稳定的根源。 本次调整,让 PawSQL 在复杂 SQL 脚本、存储过程片段、批处理审核中的稳定性明显提升。
2️⃣ Oracle / MSSQL 解析细节打磨
一些“小修复”,实际解决的是高频误报问题:
-
Oracle 函数无需括号的场景明确支持
-
SYSTIMESTAMP、CURRENT_DATE、DBTIMEZONE等
-
-
Oracle 默认字符集下,避免不必要的内建类型强转
-
MSSQL:
-
✅ 支持“换行”作为语句分隔符
-
✅ 审核前过滤涉及临时表的 SQL,避免无效失败
-
关键词只有一个:更贴近数据库真实行为,而不是“标准 SQL 理想模型”。
三、性能分析与规则引擎:更准确,也更“像专家”
🔍 Join / 子查询 / 窗口函数稳定性提升
-
修复多表 + 派生表(DT)下
USING(col)关联错误 -
子查询层级统计中,排除无 FROM 的查询块
-
修复窗口函数 clone 缺陷
-
支持从 “
a = 1 AND a <> 1”推导 恒假谓词
这些改动直接提升 PawSQL 在 TPDS 类复杂查询、OLAP 分析 SQL 中的可靠性。
📊 审核结果开始“可量化”
-
DbAuditResult引入 评分(Score)模型 -
getRows在无表上下文时增强健壮性 -
修复部分规则在边界场景下产生错误违规文本的问题
这为后续:
-
SQL 风险分级
-
优化收益排序
-
AI 辅助决策
提供了必要的数据基础。
四、审核执行引擎:为“规模化使用”而设计
如果说前面的改动偏“能力”,那么这一部分完全是工程化能力。
🚀 审核任务执行体系全面升级
11 月,PawSQL 对审核任务系统进行了结构级重构:
-
✅ 审核任务队列系统 + 缓存优化
-
✅ 动态线程池 + 事件驱动模型
-
✅ 任务超时控制,避免长时间阻塞
-
✅ 失败事件处理与加载逻辑重构
-
✅ 引入全局线程池,提升资源利用率
这解决的不是“一条 SQL”,而是:
同一时间,成百上千条 SQL 如何稳定审核?
对企业级用户来说,这往往比单条 SQL 的解析能力更重要。
五、稳定性与工程细节:减少噪音,提升可信度
-
✅ 在线解析失败时,明确返回空结果,不再回退离线解析
-
✅ 修复表名引用错误
-
✅ 巡检任务中自动排除 GaussDB
dbe_profiler模式 -
✅ Docker 镜像持续更新:
0.8.56 → 0.8.59
这些“看不见”的修复,直接影响用户对工具的长期信任度。
🌐关于PawSQL
PawSQL专注于数据库性能优化自动化和智能化,提供的解决方案覆盖SQL开发、测试、运维的整个流程,广泛支持多种主流商用、国产和开源数据库,为开发者和企业提供一站式的创新SQL优化解决方案。


1396

被折叠的 条评论
为什么被折叠?



