PawSQL 技术月报 | 2026年07月

摘要：本月，PawSQL 完成了一次重要的底层架构升级——SQL 解析器全面重构，自增主键规则按分布式/非分布式数据库自动适配。此外，PostgreSQL CREATE EXTENSION 语法获得完整支持。

一句话了解PawSQL：PawSQL 是 AI 驱动的企业级智能 SQL 审核优化平台，全球个人用户超 2 万。核心能力包括：40+ 种查询重写算法、基于代价模型的智能索引推荐、内置 300+ 规则集保障 SQL 合规安全、覆盖开发到运维全生命周期治理并支持 CI/CD 集成、兼容 MySQL、Oracle、openGauss、TDSQL 等 20 余种数据库，高效管控 SQL 质量与性能。

🚀 新功能

PostgreSQL CREATE EXTENSION 语法支持

PostgreSQL 的扩展机制是其生态一大优势。过去，包含CREATE EXTENSION的变更脚本在审核时会出现"无法解析"的误报。本月，PawSQL 新增了对CREATE EXTENSION语法的完整解析支持，您可以将其纳入审核流程并正确识别。

对您的价值：包含 CREATE EXTENSION 语句的数据库变更脚本，现在可以完整通过 PawSQL 的审核流水线。

🔧 功能提升

SELECT * 审核范围收紧：除 EXISTS 外一律提示

很多团队都将"禁止 SELECT *"列为 SQL 规范的红线——它会带来无谓的 IO 开销，也让查询对表结构变化更加脆弱。但此前 PawSQL 存在一个"漏网"场景：当 FROM 子句是单个子查询时，例如SELECT * FROM (SELECT ...) t，规则不会给出提示，规范在落地时留了一个缺口。

本月调整了RuleStarInSelectList规则的判断逻辑，取消了这一豁免。现在，除了 EXISTS 谓词内部的SELECT *（语义上仅用于存在性判断）之外，其他所有场景的SELECT *都会触发告警。

对您的价值：团队可以更彻底地执行"禁止 SELECT *"规范，审核不留死角，帮助您减少无效列读取，降低查询的 IO 与网络开销。

自增主键审核规则适配分布式数据库

自增列做主键，在集中式数据库中是标准推荐；但在分布式/分片数据库中，自增列无法保证全局唯一，用它做主键反而是典型的反模式。此前 PawSQL 主要是通过对这两类场景配置不同的模块来实现区分，模板配置错误容易发生误报，本次在规则实现层面就按数据库类型做了区分：

"主键应使用自增列"（IncColumn4PrimaryKeyRequired）：仅在非分布式数据库生效

"主键不应使用自增列"（IncColumn4PrimaryKeyDisallowed）：仅在分布式/分片数据库生效

对您的价值：无论您的数据库是集中式还是分布式，自增主键相关审核建议都能与实际架构匹配，消除误报隐患。

DML 影响行数阈值下调：1000 行即预警

一次 UPDATE/DELETE 影响的行数越多，往往意味着缺少 WHERE 条件或存在误操作风险，还可能长时间占用锁、拖慢业务。此前影响行数超过 5000 行才会触发预警，对于很多中小数据量的业务来说，风险暴露偏晚。

本月将RuleRowsOfDMLExceedThreshold规则的默认阈值从5000 行下调至 1000 行。

对您的价值：大范围 DML 操作会被更早发现和拦截，降低误删改与长事务锁的风险。

🔧 重构与健壮性

SQL 解析器全面重构：更清晰、更统一

这是本月最重磅的底层改动——SQL 解析器全面重构：

废弃老旧解析器：移除了已不再维护的独立 Oracle 和 PostgreSQL 解析器代码（移除约 3.4 万行废弃代码），全面切换至PLSQL/PGSQL脚本解析器。

统一 Script 解析器：将各数据库的脚本解析器抽象为统一的AbstractScriptParser基类，大幅减少重复代码

统一 transferSQL 方法：Advisor 模块使用统一的 SQL 转换方法，消除了多套代码间的不一致

减少不必要的查询块标记：优化了查询块的标记逻辑，避免过度标记导致的误判

对您的价值：底层架构的统一，意味着未来新数据库的接入速度会更快，解析行为也更一致。

分区定义归类到 TableOption

此前，分区定义（PARTITION BY ...）在解析树中的位置不够统一，各数据库的解析方式存在差异。本月将分区定义统一归类到tableOption中，使分区信息的提取和判断更加一致。

对您的价值：分区表相关的审核和优化逻辑更加统一，跨数据库的分区信息处理更加可靠。

非 DDL 语句不再检查表/列存在性

过去，PawSQL 对所有 SQL 语句都会检查引用的表和列是否存在。但SET、SHOW、USE DATABASE等非 DDL 语句本身不涉及元数据校验。优化后，这些语句被明确排除在检查之外，减少了约 30% 的不必要元数据查询，审核速度更快，误报更少。

对您的价值：日常运维类 SQL（如 SET variables、SHOW STATUS）不再触发元数据检查，审核响应更快，误报率降低。

上下文无 Table 时不再自动创建

在 SQL 解析过程中，如果上下文中找不到对应的Table，此前解析器会自动创建一个基础表对象，这可能会影响业务 SQL 的判断准确性（例如误以为某张表存在）。本月修复了此行为：当找不到 Table 时，不再自动创建，而是如实报告表不存在。

对您的价值：表存在性判断更加准确，避免因自动创建 Table 导致的误判。

⚡ 性能优化

PostgreSQL/openGauss 批量写入性能提升

使用 PawSQL 对 PostgreSQL 或 openGauss 数据库执行批量结果写入（如批量插入审核数据、索引推荐结果）时，JDBC 默认逐条发送插入语句，数据量大时耗时较长。

本月为 PostgreSQL/openGauss 的 JDBC 连接地址增加了reWriteBatchedInserts=true参数，驱动会自动将多条 INSERT 改写为单条多值插入，大幅减少网络往返；同时为本地连接显式关闭 SSL（ssl=false&sslmode=disable），降低握手开销。

对您的价值：批量写入场景下数据库交互次数大幅减少，审核和优化任务的整体耗时明显缩短。

SQL 解析器支持对象命名详细分析

本月优化了解析器对对象命名的分析能力——解析现在能够更细致地提取 SQL 中出现的表名、列名、别名等对象名称的详细信息。同时，语法问题的预警逻辑也得到了优化，当 SQL 存在语法歧义时，能给出更精准的预警信息。

对您的价值：语法问题预警更加精准，不再出现"看不太懂"的模糊提示。

解析器代码更新与脚本解析统一

针对 PLSQL、TSQL、PgSQL 中单条 SQL 使用脚本解析器的场景进行了统一处理，确保各数据库类型在脚本解析模式下行为一致，避免了因解析器不同导致的审核结果差异。

对您的价值：跨数据库的脚本解析行为更加一致，同一 SQL 在不同数据库类型下审核结果差异更小。

🐛 Bug 修复

MERGE INTO 语句：WHEN NOT MATCHED THEN 解析已修复

MERGE INTO 是数据同步与 ETL 场景的高频写法，形如MERGE INTO target t USING source s ON (...) WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT (...) VALUES (...)。此前，当WHEN NOT MATCHED THEN INSERT子句带有目标列清单时，解析出的列可能错误地归属到源表或未绑定任何表，导致后续审核与优化结果出现偏差。

问题根源在于：解析器在遍历 MERGE 的 WHEN 分支时，没有将"当前对象"切换到目标表，INSERT 目标列因而无法正确关联目标表表达式。本月已在遍历 WHEN 分支期间将当前对象临时切换到目标表，并增强了 INSERT 目标列的解析逻辑，确保列正确绑定到目标表。该修复同时覆盖 MySQL、PostgreSQL、Oracle(PL/SQL)、SQL Server(T-SQL) 等全部方言解析器。

对您的价值：MERGE INTO 语句（含 WHEN NOT MATCHED 分支）的审核结果列归属准确，基于此的索引推荐与优化建议也更可靠。

INSERT SELECT 语句审核信息定位修复

在审核INSERT INTO t SELECT ...这类语句时，如果报告中的 SQL 片段不完整或行号定位偏移，您很难在脚本中快速找到对应语句，尤其是在多语句脚本里。

问题根源在于：解析时仅为 INSERT 的值子句部分构建了位置信息，导致整体语句的 SQL 文本和行号只覆盖了子句片段，而非完整语句。修复后，位置信息基于完整 INSERT 语句构建，审核结果对象也直接携带语句全文，并同步覆盖全部方言解析器。

对您的价值：INSERT SELECT 语句在审核报告中能够完整展示并精确定位，多语句脚本的审核结果一目了然。

Oracle GROUP BY 位置语法已修正

Oracle 中GROUP BY 23表示按 SELECT 列表中第 23 列分组，是 Oracle 独有的语法。此前解析器未正确处理这种"按位置分组"的语义。修复后，Oracle 的GROUP BY位置语法与其他数据库的标准GROUP BY列名语法能被正确区分和解析。

对您的价值：Oracle 数据库的 GROUP BY 位置语法不再导致解析错误，审核和优化可以完整覆盖 Oracle 特有写法。

派生表转 LATERAL JOIN 关键修复：表顺序问题解决

DerivedTable2LateralJoinRewrite是 PawSQL 最受关注的优化规则之一（将 Top-N 分组查询从全量窗口函数排序改写为逐组 LIMIT）。本月修复了一个关键缺陷：当同一个查询中存在多个派生表且它们之间存在依赖关系时，LATERAL 变换后的表顺序可能与原始 SQL 不一致，导致结果集列顺序错乱。

修复后，LATERAL JOIN 的生成顺序严格遵循原始查询中的表引用顺序，结果集与原始 SQL 完全一致。

对您的价值：派生表转 LATERAL JOIN 后，结果集列顺序不再错乱，业务代码无需额外调整。

🌐 关于 PawSQL

PawSQL 是一款专业的企业级 SQL 质量管理和优化平台，提供 SQL 审核、优化、索引推荐、慢查询分析等全方位功能。支持 MySQL、PostgreSQL、Oracle、SQL Server 等主流数据库，以及 TDSQL、GaussDB 等国产数据库。为开发者和企业提供一站式的全生命周期 SQL 质量审核和优化解决方案。