SQL 查询生成

基于 AE 系统数据规范和 Trino SQL 语法，从业务需求自动生成合规的查询 SQL，配套事件表/用户表结构和分区字段规范，让 SQL 编写从"凭记忆猜测"升级为"按规范生成"。

数据采集

数据工程全行业

Generate SQL Skill 是 ThinkingAI 行业 Skill 库中的一项 SQL 生成能力，帮助数据与运营团队基于 AE 系统数据规范（事件表/用户表结构、分区字段、字段命名规则）和 Trino/Presto SQL 语法，从业务需求自动生成合规的查询 SQL——覆盖单事件查询、多事件查询、事件+用户关联查询、异常玩家排查等常见场景，让 SQL 编写从"凭记忆猜测字段名和分区条件"升级为"按规范生成零语法错误"的精准模式。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。

Agent存为 Agent导出会话

generate-sql-query

帮我写个 SQL：查渠道 suspect_channel 的玩家在 3 月 1 号到 2 号的关键行为事件分布。我自己写的那版跑了十分钟直接超时了。

通过 MCP 获取项目信息

project_id=2，事件表 ta.v_event_2

确认「关键行为」事件清单

从元数据匹配：login / battle_start / payment / item_use

按 AE 数据规范生成 SQL — 分区条件、字段双引号、group by 规范

语法校验与执行

9.4 秒返回，扫描分区 2 个

SQL 写好并已验证执行。先说你那版为什么超时：没加 `$part_date` 和 `$part_event` 分区条件——AE 事件表按日期和事件名分区，缺分区条件等于全表扫描数年明细，超时是必然的。

一、合规版 SQL

sql

SELECT
  "$part_event"                AS event_name,
  COUNT(*)                     AS event_count,
  COUNT(DISTINCT "#user_id")   AS user_count
FROM ta.v_event_2
WHERE "$part_date" BETWEEN '2026-03-01' AND '2026-03-02'
  AND "$part_event" IN ('login', 'battle_start', 'payment', 'item_use')
  AND "channel" = 'suspect_channel'
GROUP BY "$part_event"
ORDER BY event_count DESC
LIMIT 100

二、规范要点（下次自己写也能避坑）

$part_date + $part_event 必须进 WHERE——只扫命中的分区，本次查询从超时降到 9.4 秒

字段名一律加双引号——Trino 会把裸标识符转小写，#user_id 这类字段不加引号直接报错

GROUP BY 用原字段名或位置编号，不能用 SELECT 别名

默认加 LIMIT 兜底，避免误查全量拖垮查询队列

三、执行结果

事件	事件量	触发用户数	人均次数
login	48,213	8,632	5.6
battle_start	12,401	3,207	3.9
item_use	3,120	1,872	1.7
payment	89	41	2.2

← 左右滑动查看

顺带指出一个数据特征：该渠道两天内 8,632 人登录，但只有 37% 的人发起过战斗，付费用户仅 41 人——登录量大、核心行为稀薄，行为结构明显异于正常渠道。

建议

这个分布形态符合刷量渠道的典型特征。如果要下结论，建议用「渠道质量分析」Skill 做完整的六维评估（留存 / 付费 / LTV / ROI 交叉），单看事件分布还不够。

SQL 已保存至项目查询库「渠道行为排查」，可直接复用改参。

行业痛点

AE 系统的 SQL 查询是数据洞察的重要手段，但超过 60% 的写 SQL 团队踩到同样的坑：不知道事件表名是 ta.v_event_{project_id}，不知道必须加 $part_date 和 $part_event 分区条件，否则查询极慢；不知道字段名必须加双引号避免 Trino 识别错误；不知道 group by 不能用 select 别名。凭记忆写的 SQL 语法错误率超过 40%，慢查询比例超过 50%。

核心价值

AE 数据规范内置：事件表（ta.v_event_{project_id}）和用户表（ta.v_user_{project_id}）的结构、分区字段、关键字段全部内置
分区字段强制：$part_date 和 $part_event 必须出现在 WHERE 条件中，避免全表扫描导致慢查询
Trino 语法合规：字段名加双引号、group by 用原字段名或位置编号不能用别名、默认 limit 100 限制结果量
4 种常见场景模板：单事件查询、玩家行为查询、事件+用户关联查询、异常玩家排查，按场景自动选择模板
不猜测不随机：project_id、事件名、属性名全部从上下文或 MCP 查询获取，不随机生成

适用场景

需要编写查询特定事件数据的 SQL（如查询注册用户的渠道分布）

需要编写查询特定玩家行为序列的 SQL（如查看某玩家的登录/付费行为）

需要编写关联事件表和用户表的 SQL（如查询付费用户累计充值金额）

需要编写排查异常玩家的 SQL（如查看某渠道玩家的事件分布和异常模式）

需要确认 AE 系统的事件表/用户表结构和分区字段规范

已有报表/MCP 能覆盖的数据需求优先用 ae-analysis 而非手动写 SQL

实战案例

某运营团队 · 异常渠道玩家行为查询

团队需要查询渠道 suspect_channel 的玩家在 3 月 1-2 日关键行为分布，手写 SQL 因忘记加 $part_date 和 $part_event 分区条件导致超时。Generate SQL Skill 自动生成合规 SQL：使用 v_event_2 事件表，添加事件与日期分区过滤，字段名加双引号，group by 使用原字段名。查询从超时改为 10 秒内返回结果，语法零错误。

常见疑问

为什么必须加分区条件？

AE 事件表按日期（$part_date）和事件名（$part_event）分区，不加分区条件会触发全表扫描导致查询极慢甚至超时。

为什么字段名要加双引号？

Trino/Presto SQL 中不加双引号的标识符会被自动转为小写，导致与 AE 系统实际字段名不匹配。加双引号可保留原始大小写。

和 ae-analysis 有什么区别？

如果数据需求可通过 ae-analysis 的报表查询或 Builder Ad-hoc 覆盖，优先用 ae-analysis；generate-sql 仅在需要自定义 SQL 查询时使用。