接手看不懂的 PostgreSQL 查询：用 DBeaver AI 拆解，再用执行计划验证

预计阅读时间：10 分钟

生产环境里经常会出现一种“跨过围栏扔过来”的 SQL：多层 CTE、相关子查询、窗口函数和含义模糊的别名挤在一起，原作者已经联系不上，但你仍然要判断它做什么、是否正确，以及为什么这么慢。DBeaver Community Edition 26.1.2 将 AI Assistant 加入免费开源版本，为这类查询提供了一个实用的阅读入口。

AI 可以快速解释查询结构，但它不是数据库执行器。更可靠的工作方式是：让 AI 建立初步心智模型，再用表结构、样本数据和 PostgreSQL 执行计划逐项验证。

先把 SQL 拆成数据流

考虑下面这条查询：

WITH film_revenue AS (
    SELECT
        f.film_id,
        f.title,
        c.name AS category_name,
        COUNT(r.rental_id) AS rental_count,
        SUM(p.amount) AS total_revenue
    FROM public.film AS f
    JOIN public.film_category AS fc
      ON f.film_id = fc.film_id
    JOIN public.category AS c
      ON fc.category_id = c.category_id
    JOIN public.inventory AS i
      ON f.film_id = i.film_id
    JOIN public.rental AS r
      ON i.inventory_id = r.inventory_id
    JOIN public.payment AS p
      ON r.rental_id = p.rental_id
    GROUP BY f.film_id, f.title, c.name
),
ranked_films AS (
    SELECT
        film_id,
        title,
        category_name,
        rental_count,
        total_revenue,
        ROW_NUMBER() OVER (
            PARTITION BY category_name
            ORDER BY rental_count DESC, total_revenue DESC
        ) AS rank
    FROM film_revenue
)
SELECT title, category_name, rental_count, total_revenue
FROM ranked_films
WHERE rank <= 10
ORDER BY category_name, rank;

这条 SQL 可以沿着三个阶段阅读：

film_revenue 把影片、分类、库存、租赁和付款连接起来，按影片及分类汇总租赁次数和收入。
ranked_films 在每个分类内部排序，优先比较租赁次数，再比较收入。
最外层保留每个分类排名前 10 的影片，并按分类和名次输出。

因此，它的业务意图是“找出每个分类最受欢迎的 10 部影片，并展示对应收入”。这种阶段式描述比逐行复述语法更有价值，因为它能直接交给业务人员确认。

在 DBeaver 中怎样提问

根据来源说明，DBeaver 26.1.2 的 AI Assistant 位于主菜单 AI 下，并可配置 OpenAI 等模型服务。打开助手后，不要只问一句“这段 SQL 做什么”。可以这样实践，提交一个约束更明确的提示词：

请分析下面的 PostgreSQL 查询，并按以下格式回答：

1. 用一句话说明业务目的。
2. 按 CTE、子查询和最终 SELECT 分阶段解释数据如何变化。
3. 列出每个 JOIN 的基数风险，以及可能导致重复计数的位置。
4. 说明窗口函数的分区、排序和并列值处理方式。
5. 指出 NULL、空结果和一对多关联可能造成的语义问题。
6. 给出更易读的等价改写，但不要假设未提供的表约束。
7. 不要执行查询，也不要声称已经检查真实数据。

SQL:
<在这里粘贴查询>

这类提示词要求 AI 区分“查询意图”和“查询是否真的实现了意图”。两者并不总是相同。例如，模型可以识别 SUM(p.amount) 在统计收入，却无法仅凭 SQL 确认一条租赁是否可能对应多条付款记录，也不能确认分类名称是否唯一。

处理生产 SQL 时还要注意信息边界。查询文本可能暴露表名、字段名、租户规则或业务流程。使用外部模型前，应确认公司的数据处理政策；尽量只提交 SQL 结构，移除字面量、客户标识、注释和样本数据。若模型配置不受团队控制，不应直接粘贴敏感查询。

AI 解释之后，用 PostgreSQL 验证

不要因为解释读起来合理就直接重写或上线。先在测试环境或只读副本上检查执行计划。将查询保存为 query.sql，替换连接参数后，可以运行：

psql "postgresql://readonly_user@localhost:5432/dvdrental" \
  -v ON_ERROR_STOP=1 \
  -c "EXPLAIN (VERBOSE, COSTS, FORMAT TEXT) $(tr '\n' ' ' < query.sql)"

普通 EXPLAIN 不执行查询，适合先查看计划结构。若要获得真实行数和耗时，可以在确认查询为只读、数据规模可控且运行窗口合适后，改用：

psql "postgresql://readonly_user@localhost:5432/dvdrental" \
  -v ON_ERROR_STOP=1 \
  -c "EXPLAIN (ANALYZE, BUFFERS, VERBOSE, FORMAT TEXT) $(tr '\n' ' ' < query.sql)"

EXPLAIN ANALYZE 会真实执行语句，不能把它当作无害的语法检查。面对未知 SQL，还应先确认它不是 INSERT、UPDATE、DELETE、DDL 或调用带副作用的函数，并设置超时。可以这样实践：

BEGIN READ ONLY;
SET LOCAL statement_timeout = '5s';
SET LOCAL lock_timeout = '1s';

EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT current_database(), now(); -- 替换为已确认只读的查询

ROLLBACK;

验证时重点比较估算行数与实际行数，检查是否出现大规模顺序扫描、重复执行的相关子查询、磁盘排序，以及连接后行数突然膨胀。AI 可以指出可疑结构，执行计划才会告诉你数据库实际上做了什么。

复杂子查询为什么尤其值得警惕

同一个“每类前 10 名”需求也可能写成多层相关子查询：对每部影片分别统计租赁和收入，再通过另一个子查询计算有多少同类影片的租赁次数更高。这种写法虽然可能表达相近意图，却有几个明显风险：

相同的库存和租赁统计逻辑被重复计算，阅读成本和执行成本都可能上升。
以“有多少影片严格大于当前影片”判断前 10 名，会产生并列语义；多个影片可能同时进入结果，最终不一定每类恰好 10 行。
旧式逗号连接把关联条件藏在 WHERE 中，更容易漏写条件并产生笛卡尔积。
a、b、x、RevCntr1 一类别名没有表达领域含义，增加维护者的认知负担。

窗口函数版本通常更容易审查，但也要明确排名规则。ROW_NUMBER() 会强制给并列记录不同名次；如果业务要求并列影片共享名次，应评估 RANK() 或 DENSE_RANK()。若要求结果稳定，还应增加唯一的最终排序键，例如 film_id：

ROW_NUMBER() OVER (
    PARTITION BY category_name
    ORDER BY rental_count DESC, total_revenue DESC, film_id
) AS category_rank

这不是无条件的“优化模板”，而是把并列处理从偶然行为变成明确规则。

接入团队流程时保留三道检查

DBeaver AI Assistant 适合承担快速导读、术语解释和初步重构建议，尤其适合第一次接触陌生 CTE、窗口函数或相关子查询时。但在采纳结论前，至少完成三项检查：

语义检查：让表结构、约束和业务负责人确认计数单位、收入口径及并列规则。
执行检查：使用 EXPLAIN，必要时在受控环境运行 EXPLAIN ANALYZE，核对真实行数和资源消耗。
安全检查：确认查询只读，设置超时，并遵守向外部模型提交数据库元数据的政策。

AI 能把一团 SQL 更快地整理成可讨论的假设，却不能替代数据库证据。把它当作阅读助手，再用 PostgreSQL 自身的工具完成验证，才是接手陌生查询时更稳妥的工作流。