DBeaver Community Edition 已经支持交互式 AI 对话。对数据库开发者来说，这并不只是编辑器里多了一个聊天窗口：它可以根据自然语言生成 SQL、解释查询，并给出索引优化建议。真正值得关注的是，AI 缩短了从“业务问题”到“可执行查询”的距离，但执行计划、数据语义和上线风险仍然需要工程师把关。
自然语言先生成草稿，再由人确认语义
假设使用 PostgreSQL 的 DVD Rental 示例数据库，我们想知道“租赁次数最多的十部电影，以及它们产生的收入”。过去通常要先查看 film、inventory、rental 和 payment 的表结构，再手写多表连接。现在可以直接向 DBeaver 中的 AI 提问：
What are the top ten most popular rentals and how much revenue did they generate?
来源示例使用 DBeaver Community Edition 26.1.3 和 GitHub Copilot GPT-4.1，生成了下面这类查询：
SELECT
f.film_id,
f.title,
COUNT(r.rental_id) AS rental_count,
COALESCE(SUM(p.amount), 0) AS total_revenue
FROM film AS f
JOIN inventory AS i
ON f.film_id = i.film_id
JOIN rental AS r
ON i.inventory_id = r.inventory_id
LEFT JOIN payment AS p
ON r.rental_id = p.rental_id
GROUP BY f.film_id, f.title
ORDER BY rental_count DESC, total_revenue DESC
LIMIT 10;
这段 SQL 展示了 AI 的直接价值：它能够识别表之间的连接路径，补齐聚合、排序和空值处理，并快速交付一个可运行的查询草稿。
不过，生成成功不等于语义必然正确。如果一条租赁记录可能对应多条支付记录，连接 payment 后，COUNT(r.rental_id) 会重复计算租赁次数。更稳妥的写法取决于业务定义。可以这样实践：明确要求统计“不同租赁记录”，并使用 COUNT(DISTINCT ...)。
SELECT
f.film_id,
f.title,
COUNT(DISTINCT r.rental_id) AS rental_count,
COALESCE(SUM(p.amount), 0) AS total_revenue
FROM film AS f
JOIN inventory AS i
ON i.film_id = f.film_id
JOIN rental AS r
ON r.inventory_id = i.inventory_id
LEFT JOIN payment AS p
ON p.rental_id = r.rental_id
GROUP BY f.film_id, f.title
ORDER BY rental_count DESC, total_revenue DESC
LIMIT 10;
在真实系统中，还应继续确认“热门”究竟按租赁次数、独立客户数还是时间窗口定义，收入是否包含退款、税费和取消订单。AI 能生成语法，却不知道团队未写入提示词的业务规则。
索引建议不能跳过现场检查
针对上述查询，AI 建议关注三个连接列：
inventory(film_id)：按电影查找库存副本。rental(inventory_id)：按库存副本查找租赁记录。payment(rental_id)：按租赁记录查找支付数据。
在 PostgreSQL 中，外键约束不会自动为引用列创建索引，因此这些建议具有现实意义。但不要直接重复创建索引。可以先运行下面的查询，检查相关表已经存在的索引：
SELECT
schemaname,
tablename,
indexname,
indexdef
FROM pg_indexes
WHERE schemaname = 'public'
AND tablename IN ('inventory', 'rental', 'payment')
ORDER BY tablename, indexname;
确认缺失后，可以这样创建：
CREATE INDEX IF NOT EXISTS idx_inventory_film_id
ON inventory (film_id);
CREATE INDEX IF NOT EXISTS idx_rental_inventory_id
ON rental (inventory_id);
CREATE INDEX IF NOT EXISTS idx_payment_rental_id
ON payment (rental_id);
IF NOT EXISTS 只能避免同名索引冲突，不能识别“名称不同但结构相同”的重复索引。因此，创建之前仍要阅读 indexdef。索引也不是免费的：它会占用磁盘，并增加 INSERT、UPDATE 和 DELETE 的维护成本。
用执行计划验证 AI 的判断
索引存在，并不代表 PostgreSQL 一定会使用它。小表上的顺序扫描可能比索引扫描更便宜；聚合大量行时，瓶颈也可能出现在排序、哈希聚合或磁盘临时文件，而不是连接列。
可以这样实践：在测试环境执行 EXPLAIN (ANALYZE, BUFFERS)，用真实执行数据比较建索引前后的计划。
EXPLAIN (ANALYZE, BUFFERS)
SELECT
f.film_id,
f.title,
COUNT(DISTINCT r.rental_id) AS rental_count,
COALESCE(SUM(p.amount), 0) AS total_revenue
FROM film AS f
JOIN inventory AS i
ON i.film_id = f.film_id
JOIN rental AS r
ON r.inventory_id = i.inventory_id
LEFT JOIN payment AS p
ON p.rental_id = r.rental_id
GROUP BY f.film_id, f.title
ORDER BY rental_count DESC, total_revenue DESC
LIMIT 10;
重点观察实际耗时、估算行数与实际行数的偏差、Buffers 读写量，以及是否出现成本较高的顺序扫描。ANALYZE 会真正执行查询；对于写操作或昂贵查询，不应未经评估直接在生产环境运行。
如果索引刚创建、数据又发生过大规模变更，还可以更新统计信息：
ANALYZE inventory;
ANALYZE rental;
ANALYZE payment;
生产环境的大表通常需要考虑 CREATE INDEX CONCURRENTLY，以减少普通建索引对写入的阻塞。该命令不能放在显式事务块中，而且执行时间更长、失败后可能留下无效索引，必须结合运维流程使用。
把 AI 放在正确的位置
DBeaver 的 AI 对话适合承担查询起草、SQL 解释、索引候选分析和数据库探索等工作。团队采用时可以保留一条清晰的验证链：
- 提示词写明数据库类型、统计口径、时间范围和结果粒度。
- 执行前检查连接关系、空值处理以及一对多连接造成的重复计数。
- 查询系统目录，确认索引是否已经存在或被其他复合索引覆盖。
- 使用
EXPLAIN或EXPLAIN ANALYZE验证优化建议，而不是根据文字说明上线。 - 将生成 SQL 当作需要评审的代码，避免向 AI 暴露敏感数据、凭据和不必要的生产元数据。
AI 可以让开发者更快抵达第一版 SQL，却不能替代对业务口径、执行计划和生产变更风险的判断。最有效的工作方式，是让它负责加速探索，让数据库工程流程负责证明结果。