Trino 元数据检查与查询分析

通过 MCP 工具检查 Trino catalog、schema、table 结构，分析 SQL 执行计划与查询运行状态，让数据工程师告别盲写 SQL。

数据采集

数据工程全行业

Trino 元数据检查与查询分析 Skill 是 ThinkingAI 行业 Skill 库中的一项数据工程能力，帮助数据工程师通过 MCP 工具检查 Trino 数据源的 catalog、schema、table 结构，分析 SQL 执行计划（EXPLAIN / EXPLAIN ANALYZE），查看历史查询记录与运行状态，从"盲写 SQL"升级为"先看元数据再看执行计划再写 SQL"的数据驱动模式。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。

Agent存为 Agent导出会话

trino-metadata-query-analysis

我要给新来的同事整理一份项目数据表清单——ta 库里到底有哪些事件表、用户表，各表多大、多少个分区，说实话我自己也说不全。帮我从元数据里查一遍，别动业务数据。

MCP list_catalogs / list_schemas 导航数据源

定位 catalog hive → schema ta

查询 information_schema.tables 盘点事件表与用户表

命中 4 张：v_event_2 / v_user_2 / v_event_5 / v_user_5

读取 v_event_2$partitions 分区元数据 — 统计分区数与日期覆盖

get_table_schema 确认关键字段类型

$part_date / $part_event 为分区键，pay_amount 为 numeric

汇总表清单、分区规模与查询注意事项

清单整理好了，全程只读元数据、没扫一行业务数据。ta 下共 4 张核心表，主力事件表 ta.v_event_2 有 14,560 个分区、约 1.8 TB——这张表不带分区条件查询，等于一次全表扫 1.8 TB。

一、元数据查询 SQL

sql

-- 1. 盘点 ta schema 下的事件表与用户表
SELECT "table_name", "table_type"
FROM information_schema.tables
WHERE "table_schema" = 'ta'
  AND ("table_name" LIKE 'v_event_%' OR "table_name" LIKE 'v_user_%')
ORDER BY "table_name";

-- 2. 统计主力事件表的分区规模（只读分区元数据，不扫业务数据）
SELECT
  COUNT(*)          AS partition_count,
  MIN("$part_date") AS earliest_date,
  MAX("$part_date") AS latest_date
FROM ta."v_event_2$partitions"

二、表清单与分区规模

表	用途	分区数	数据量	最新分区
ta.v_event_2	生产项目事件表	14,560	1.8 TB	2026-07-16
ta.v_user_2	生产项目用户表	非分区	4.2 GB	—
ta.v_event_5	测试项目事件表	1,236	96 GB	2026-07-16
ta.v_user_5	测试项目用户表	非分区	310 MB	—

← 左右滑动查看

v_event_2 的 14,560 个分区由 728 个日期分区 × 20 个事件分区组成，日期覆盖 2024-07-19 至 2026-07-16。给新同事划两个重点：① 分区键是 $part_date + $part_event，任何查询这两个条件必须进 WHERE；② pay_amount 是 numeric 类型，别按字符串比较——项目历史上出过按 string 处理导致金额统计偏差的先例。

建议

建议把这份清单固化进新人入门文档，并配一条写 SQL 前的固定动作：先查元数据（表结构 → 分区键 → 字段类型），再用 EXPLAIN 看执行计划，最后才写查询。凭猜写 SQL 的调试成本是 2–3 小时起步，查一遍元数据只要 1 分钟。

本次所有操作均为只读检查，未创建或修改任何对象。

行业痛点

数据工程师在 Trino 环境下写 SQL 时，约 70% 的错误源于"不了解数据结构就直接写"——不知道表有哪些列、列的数据类型和分区字段，凭猜测写出的 SQL 报错后需要反复调试，平均一条复杂 SQL 的调试周期为 2-3 小时。更隐蔽的问题是执行计划分析能力缺失，慢查询根因在 EXPLAIN 输出中一目了然，但多数工程师不会读，只能靠盲目试错。

核心价值

元数据导航：从 catalog → schema → table → column 逐层检查数据结构，写 SQL 前先确认字段名和数据类型
执行计划分析：支持 EXPLAIN（静态计划）和 EXPLAIN ANALYZE（运行实测），输出 TEXT/JSON/GRAPHVIZ 多种格式
查询记录检查：查看历史查询的运行状态、资源消耗、排队信息，追踪已提交任务
严格的只读边界：所有操作均为检查和查看，不修改数据不创建表，安全可靠

适用场景

写 SQL 前需要确认表结构、字段名、数据类型和分区字段

慢查询需要通过执行计划分析瓶颈节点

已提交查询需要查看运行状态和资源消耗

不确定 Trino catalog/schema 命名时需要导航发现

SQL 调优前需要对比不同写法的执行计划差异

实战案例

某数据工程师 · Trino 表结构确认与执行计划分析

工程师不确定事件表分区字段和列名。Skill 先用 list_catalogs 和 list_schemas 导航数据源，再用 get_table_schema 确认 #part_date、#part_event 是分区字段，pay_amount 是 numeric 类型。编写 SQL 后用 explain_query 发现 Sort 节点开销占 80%，改写添加 LIMIT 与分区过滤后，查询时间从 45 分钟降至 12 秒。

常见疑问

这个 Skill 能修改数据吗？

不能。所有操作均为只读检查：查看元数据、分析执行计划、查看查询状态，不修改任何数据或创建任何对象。

EXPLAIN 和 EXPLAIN ANALYZE 有什么区别？

EXPLAIN 生成静态计划文本，不执行查询；EXPLAIN ANALYZE 会实际执行查询并返回运行实测数据。

和 AE SQL 性能优化 Skill 有什么区别？

Trino 元数据检查侧重"先看结构再写 SQL"的预防性检查，SQL 性能优化侧重已有慢查询的改写方案。两者互补。

Trino 元数据检查与查询分析

一、元数据查询 SQL

二、表清单与分区规模

行业痛点

核心价值

适用场景

实战案例

常见疑问

这个 Skill 能修改数据吗？

EXPLAIN 和 EXPLAIN ANALYZE 有什么区别？

和 AE SQL 性能优化 Skill 有什么区别？

相关 Skills 推荐

用「Trino 元数据检查与查询分析」武装你的 Agent

Agent

产品能力

语言选择