运营小伙伴丢过来一句话：“拉一下上季度华东区复购率最高的三个品类，顺带把各渠道的GMV趋势也一起看下。”——表在四个库里，得JOIN四张表，还得嵌套子查询加窗口函数。手动撸SQL？少说二十分钟起步，还不一定一次跑对。现在用阶跃AI，把这句话丢进去，三秒出可运行的多表联查语句。这可不是画饼，往下看，一步步教你把它落地。

第一步：连上数据库并加载Schema

打开阶跃AI控制台，进「SQL Assistant」模块，点「绑定数据库」，填好MySQL或PostgreSQL连接信息（host、port、username、password、database name），勾上「自动同步元数据」，最后点「确认连接」。

这一步必须到位，【未同步Schema就提问，AI只能靠猜表结构，三表以上JOIN几乎必翻车】。连接成功后，右上角会显示“已加载XX张表”，字段名、类型、主键、外键注释全部一目了然。

第二步：用自然语言描述需求，但必须带约束条件

在AI输入框里粘贴完整描述，比如：

“查上季度华东区复购率最高的三个商品品类，复购率=购买次数≥2的用户数 / 总用户数；同时显示每个品类在抖音、淘宝、京东三个渠道的GMV月度趋势（2024-04至2024-06）。涉及表：users（id, city_id）、orders（id, user_id, amount, created_at, channel）、products（id, category）、cities（id, region）。”

注意，不能只讲“查复购率”——必须明确定义计算逻辑；不能只讲“看渠道GMV”——得把具体渠道名列出来；表名和关键字段必须显式写出，否则AI没法定位外键路径（比如orders.user_id → users.id）。

第三步：生成后立刻校验三处硬伤

拿到SQL先别急着执行，对着三处关键点逐条过：

第一，检查FROM后的主表是否合理。目标是“品类复购率”，主表就该是products或category维度表，而不是users或orders。

第二，逐行核对ON条件，重点看箭头方向：【orders.user_id = users.id 是对的，orders.id = users.id 就是灾难性错误】——后者一跑就是笛卡尔积，十分钟不出结果。

第三，确认WHERE里的时间过滤是否落在最外层。如果“上季度”条件被写进子查询却没同步到主查询，结果会漏掉大量数据。

第四步：针对多表JOIN做定向修正

如果生成的JOIN不太对路，有三个补丁打法：

方法一：强制指定JOIN类型。在原始提问末尾追加一句：“必须用LEFT JOIN连接users和orders，因为要保留未下单用户用于分母计算。”

方法二：锁定关联字段。在输入框里补充：“外键关系仅允许：orders.user_id→users.id，orders.product_id→products.id，users.city_id→cities.id。”

方法三：拆解嵌套逻辑。如果AI把复购率计算和GMV趋势塞进同一个SELECT，立刻重提需求：“先用子查询算出top3品类，再用主查询JOIN渠道表拉GMV趋势——两个逻辑必须分离。”

第五步：执行前做一次轻量验证

① 把生成SQL复制进Na vicat或DBea ver，右键选「执行计划」，看有没有出现“Using filesort”或“Using temporary”字样；

② 如果有，说明GROUP BY字段缺失或索引没命中，立即回到阶跃AI追加提示：“优化性能：在orders(created_at, channel, user_id)上建联合索引，并改用覆盖索引扫描。”

③ 点击「执行」按钮，看返回行数是否符合业务直觉——比如华东区用户才5万人，结果却返回80万行，大概率是JOIN类型或ON条件写岔了。