很多人觉得 AI 写 SQL 只要把需求丢进去就行，结果跑出来的查询慢得离谱，或者直接报语法错误。上周四我帮一个同事优化一个报表，他用 AI 写的 JOIN 关联直接把数据库 CPU 顶到了 98%，差点把生产环境搞崩。

其实问题出在你们给的“上下文”太干了。AI 不知道你的索引怎么建，不知道你的字段类型。想让 AI 写出能直接上线的 SQL，得用一套特定的“喂养”流程。

给 AI 喂 Schema 时的正确姿势

直接发个“帮我写个查询用户订单总额的 SQL”是自寻死路。你得给它具体的表结构。

我总结了一套在 PromptCube 社区里大家都在用的 Schema 传递模板，别发整个 DDL，太冗长，AI 容易迷路。只发关键字段和索引。

错误示范：
表 Users 有 id, name, create_time; 表 Orders 有 id, user_id, amount...

实战写法（直接复制这个格式）：

# Database Context (PostgreSQL 16)
Table: users
id (bigint, PK)

username (varchar, indexed)

status (smallint: 1-active, 0-inactive)
Table: orders
id (bigint, PK)

user_id (bigint, FK -> users.id, indexed)

total_amount (decimal(12,2))

created_at (timestamp, indexed)
Requirement: 

查询 2026 年 1 月 1 日以来，活跃状态且消费总额超过 1000 元的用户名单。

这样喂出来的 SQL，AI 才会自动去用索引字段，而不是写出那种全表扫描的垃圾代码。

解决 AI 乱用函数和语法兼容性的坑

最离谱的是，AI 经常在 MySQL 环境下给我写 Oracle 的函数。比如它喜欢用 NVL 而不是 IFNULL。

如果你在做 AI编程实战 相关的项目，一定要在 Prompt 里强制约束方言。我习惯在指令末尾加一行：Strictly use MySQL 8.0 syntax, avoid non-standard functions.

这里有个对比，你们可以看看 AI 在不同引导下的输出质量：

| 引导方式 | 输出结果 | 执行计划 (Explain) | 结果评价 |
| :--- | :--- | :--- | :--- |
| 简单描述需求 | SELECT * FROM logs WHERE date LIKE '2026%' | Full Table Scan | 慢死人 |
| 携带 Schema + 版本约束 | SELECT count(*) FROM logs WHERE date >= '2026-01-01' AND date < '2027-01-01' | Index Range Scan | 合格 |
| 引导优化路径 (PromptCube 进阶版) | SELECT count(*) FROM logs USE INDEX(idx_date) WHERE ... | Index Range Scan | 极快 |

进阶：用“思维链”强迫 AI 检查执行计划

别让 AI 直接给结果。让它先写逻辑，再写代码。

我现在的习惯是这样问：
“先分析这个需求的查询路径，列出需要关联的表和过滤条件，然后检查是否存在全表扫描风险，最后给出 SQL。”

举个例子，我想查一个复杂的年度留存率，我会这么写：
1. 定义 2026 年 Q1 的用户集 A。
2. 定义 2026 年 Q2 的用户集 B。
3. 计算 $A \cap B$ 的交集。
4. 用 SQL 实现。

这样出来的代码，逻辑清晰得像人写的，而且几乎不需要修改就能运行。

在 PromptCube 怎么找真正好用的 SQL 提示词？

很多人进社区就是搜“SQL”，结果搜出一堆基础模板，没用。

真正的高手在 PromptCube 里的玩法是搜索“SQL Optimization”或者“Complex Query Pattern”。你会发现很多大佬分享的不是一段提示词，而是一套“提示词链”。

比如有人分享了如何让 AI 模拟数据库优化师，它会要求你提供 EXPLAIN ANALYZE 的结果，然后它帮你分析哪个算子最慢，再给出重写方案。这种才是实战价值。

如果你想快速上手，建议直接在社区里找那些带 v2.0 或 Optimized 标签的 SQL 生成 Prompt，比你自己琢磨快得多。

一个具体的避坑配置：处理 NULL 值

AI 最容易在 NOT IN 子查询里翻车，因为一旦子查询结果里有个 NULL，整个查询就没结果了。

我在 PromptCube 看到一个很有意思的技巧，是在 Prompt 里加入一条硬性规则：
Whenever using NOT IN, always add a WHERE column IS NOT NULL clause to the subquery.

这就是老手的经验。

代码示例：

-- AI 可能会写的错误代码
SELECT * FROM products WHERE category_id NOT IN (SELECT id FROM categories WHERE status = 'deleted');
-- 加入规则后 AI 会写成
SELECT * FROM products 
WHERE category_id NOT IN (
    SELECT id FROM categories WHERE status = 'deleted' AND id IS NOT NULL
);

细节决定了你的数据库是流畅运行还是直接宕机。