SQL 性能优化
识别慢查询、不合理索引与低效写法，基于执行计划与数据库优化规则输出改写方案，让 SQL 从"跑不出来"到"秒级响应"。
数据采集
数据工程全行业SQL 性能优化是 ThinkingAI 行业 Skill 库中的一项数据工程能力，帮助开发与数据分析师在 SQL 查询过慢时识别瓶颈根因，基于执行计划分析定位不合理索引与低效写法，输出可执行的改写方案与调优建议，确保优化后结果与原始查询完全一致。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。
行业痛点
慢查询是数据团队最头疼的技术问题，但优化方向往往靠"直觉"而非"数据"。数据团队每周平均处理 3-5 条慢查询，其中 60% 的根因是写法低效而非缺索引。更隐蔽的问题是 SELECT *、低效子查询、DISTINCT 滥用、漏掉 #part_date 和 #part_event 分区过滤等写法问题会让扫描量膨胀 3-10 倍，甚至触发 Trino 全表扫描 5 亿行。
核心价值
- 执行计划驱动优化：先读执行计划定位瓶颈节点（扫描量大、排序开销高、分区未裁剪），再针对性改写而非盲目加索引
- 结果一致性保证：优化后的 SQL 必须与原始 SQL 输出完全一致（列数、列名、行数、数值精度零容忍）
- Trino 分区字段优先检查：TE 系统基于 Trino 引擎，#part_date 和 #part_event 双分区过滤是 SQL 性能的第一道关卡
适用场景
1
SQL 查询耗时过长需要优化提速
2
执行计划解读与瓶颈节点定位
3
索引设计不合理时的优化方案
4
Trino 引擎下的分区字段使用优化
5
SQL 写法低效时的改写方案（子查询→JOIN、DISTINCT→GROUP BY 等）
6
数据库架构层面的性能调优建议
实战案例
某游戏数据分析师 · 用户行为 SQL 慢查询优化
一条用户行为分析 SQL 运行 45 分钟仍未返回。Skill 检查发现缺少 #part_date 和 #part_event 过滤，导致 Trino 全表扫描 5 亿行；执行计划显示 Sort 节点消耗 80% 时间。改写后添加双分区过滤、调整 ORDER BY 字段并增加 LIMIT，扫描范围压缩至 500 万行，查询时间从 45 分钟降至 12 秒，结果与原始 SQL 完全一致。
常见疑问
优化后结果会不会有偏差？
不会。Skill 对结果一致性实行零容忍标准：列数、列名、行数、数值精度必须完全一致，并附带验证步骤。
加索引能解决所有慢查询吗？
不能。很多慢查询根因是写法低效或全表扫描，盲目加索引反而增加维护成本。Skill 会先分析执行计划再决定策略。
Trino 引擎和其他数据库的优化有什么区别？
Trino 引擎最关键的是分区裁剪。TE 事件表按 #part_date 和 #part_event 双分区存储，SQL 必须包含这两个过滤条件才能避免全表扫描。
相关 Skills 推荐
用「SQL 性能优化」武装你的 Agent
预约演示，看看它如何在你的业务场景中落地
