SQL 性能优化

识别慢查询、不合理索引与低效写法，基于执行计划与数据库优化规则输出改写方案，让 SQL 从"跑不出来"到"秒级响应"。

数据采集

数据工程全行业

SQL 性能优化是 ThinkingAI 行业 Skill 库中的一项数据工程能力，帮助开发与数据分析师在 SQL 查询过慢时识别瓶颈根因，基于执行计划分析定位不合理索引与低效写法，输出可执行的改写方案与调优建议，确保优化后结果与原始查询完全一致。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。

Agent存为 Agent导出会话

sql-performance-optimization

有条用户行为分析 SQL 昨晚跑了 45 分钟都没出来，把查询队列都堵了。SQL 我贴给你了，帮我看看到底慢在哪、怎么改。

读取原 SQL，跑 EXPLAIN ANALYZE 定位瓶颈

全表扫描约 5 亿行，Sort 节点耗时占 80%

诊断低效写法 — 缺 $part_date / $part_event 分区过滤、付费用户子查询重复计算两次、无 LIMIT 全量排序

改写 — 补双分区过滤，重复子查询抽成 WITH 中间表，聚合后排序加 LIMIT 兜底

执行验证

12.3 秒返回，扫描 512 万行

结果一致性校验 — 列数 / 列名 / 行数 / 数值精度逐项与原 SQL 比对

完全一致

改完了，也验证过了。同一条 SQL，从 45 分钟跑不完到 12.3 秒返回，扫描量从约 5 亿行压到 512 万行——瓶颈不在集群，在写法。

一、优化后的 SQL

sql

WITH pay_users AS (
  SELECT DISTINCT "#user_id"
  FROM ta.v_event_2
  WHERE "$part_date" BETWEEN '2026-06-16' AND '2026-07-15'
    AND "$part_event" = 'payment'
)
SELECT
  e."$part_date"               AS stat_date,
  e."$part_event"              AS event_name,
  COUNT(*)                     AS event_count,
  COUNT(DISTINCT e."#user_id") AS user_count
FROM ta.v_event_2 e
JOIN pay_users p ON e."#user_id" = p."#user_id"
WHERE e."$part_date" BETWEEN '2026-06-16' AND '2026-07-15'
  AND e."$part_event" IN ('login', 'battle_start', 'item_use')
GROUP BY e."$part_date", e."$part_event"
ORDER BY stat_date
LIMIT 500

二、改了三处

补上 $part_date + $part_event 双分区过滤——原 SQL 两个条件都缺，Trino 直接全表扫描约 5 亿行，这是超时的第一根因

「付费用户」子查询在原 SQL 里出现两次、每次都重算一遍，抽成 WITH 中间表 pay_users 只算一次

原 SQL 对明细做无 LIMIT 全量排序，Sort 节点吃掉 80% 耗时；改为聚合后再排序，并加 LIMIT 兜底

三、优化前后对比

指标	优化前	优化后
执行耗时	45 分钟未返回（超时）	12.3 秒
扫描行数	约 5 亿行	512 万行
Sort 节点耗时占比	80%	6%
结果一致性	—	列数 / 行数 / 数值精度完全一致

建议

这三个坑（缺分区、重复子查询、全量排序）在你们项目的慢查询里是高频组合。建议把「$part_date + $part_event 必须进 WHERE」写进团队 SQL 评审清单——在 AE / Trino 环境下，分区裁剪是性能的第一道关卡，优先级高于任何索引调优。

优化版 SQL 已回填至 IDE 查询库，原始版本已备注弃用原因。

行业痛点

慢查询是数据团队最头疼的技术问题，但优化方向往往靠"直觉"而非"数据"。数据团队每周平均处理 3-5 条慢查询，其中 60% 的根因是写法低效而非缺索引。更隐蔽的问题是 SELECT *、低效子查询、DISTINCT 滥用、漏掉 #part_date 和 #part_event 分区过滤等写法问题会让扫描量膨胀 3-10 倍，甚至触发 Trino 全表扫描 5 亿行。

核心价值

执行计划驱动优化：先读执行计划定位瓶颈节点（扫描量大、排序开销高、分区未裁剪），再针对性改写而非盲目加索引
结果一致性保证：优化后的 SQL 必须与原始 SQL 输出完全一致（列数、列名、行数、数值精度零容忍）
Trino 分区字段优先检查：AE 系统基于 Trino 引擎，#part_date 和 #part_event 双分区过滤是 SQL 性能的第一道关卡

适用场景

SQL 查询耗时过长需要优化提速

执行计划解读与瓶颈节点定位

索引设计不合理时的优化方案

Trino 引擎下的分区字段使用优化

SQL 写法低效时的改写方案（子查询→JOIN、DISTINCT→GROUP BY 等）

数据库架构层面的性能调优建议

实战案例

某游戏数据分析师 · 用户行为 SQL 慢查询优化

一条用户行为分析 SQL 运行 45 分钟仍未返回。Skill 检查发现缺少 #part_date 和 #part_event 过滤，导致 Trino 全表扫描 5 亿行；执行计划显示 Sort 节点消耗 80% 时间。改写后添加双分区过滤、调整 ORDER BY 字段并增加 LIMIT，扫描范围压缩至 500 万行，查询时间从 45 分钟降至 12 秒，结果与原始 SQL 完全一致。

常见疑问

优化后结果会不会有偏差？

不会。Skill 对结果一致性实行零容忍标准：列数、列名、行数、数值精度必须完全一致，并附带验证步骤。

加索引能解决所有慢查询吗？

不能。很多慢查询根因是写法低效或全表扫描，盲目加索引反而增加维护成本。Skill 会先分析执行计划再决定策略。

Trino 引擎和其他数据库的优化有什么区别？

Trino 引擎最关键的是分区裁剪。AE 事件表按 #part_date 和 #part_event 双分区存储，SQL 必须包含这两个过滤条件才能避免全表扫描。