用途：在本地 Materialize 实例中，用分布式追踪（OpenTelemetry / Tempo）分析 SQL 语句执行期间时间花在哪里，回答“为什么这个查询慢”“时间去哪了”等问题。
主要能力：启动本地监控栈（Tempo + Grafana + Prometheus）并让 environmentd 开启追踪；通过 emit_trace_id_notice 获取语句的 trace ID；从 Tempo HTTP API 拉取 OTLP JSON 追踪数据；用 trace_tree.py 分析 span 树，查看 self-time、父子 span 并发/串行关系，以及 group_commit_apply::append_fut、catalog::transact_inner、oracle::write_ts、consensus::compare_and_set、coord::check_consistency 等关键 span。
使用方式：先启动监控栈 bin/mzcompose --find monitoring run default，等待 Tempo 就绪；再运行 bin/environmentd --optimized --monitoring。用 psql 设置 SET emit_trace_id_notice = true; 后执行目标 SQL，取最后一条 trace id。等待约 10 秒让 span 刷出，再请求 http://localhost:3200/api/traces/$TRACE_ID，并用 python3 .claude/skills/mz-query-tracing/trace_tree.py /tmp/claude-1000/trace.json "My Query" 分析。运行时可用 ALTER SYSTEM SET opentelemetry_filter = 'debug'; 调整过滤级别。
适用场景：本地调试 Materialize 中 SQL 执行耗时、DDL 慢、catalog 或 persist 操作耗时等问题，以及对比代码改动前后的 self-time 排名。
限制：必须使用 --optimized 构建，debug 构建会产生误导性 self-time；必须先启动监控栈再启动 environmentd，否则 span 丢失；网络调用需要 dangerouslyDisableSandbox；span 有默认 5 秒批量延迟，首次拉取常返回 trace not found，需要重试；Tempo 默认仅保留 15 分钟追踪数据。其余细节暂未提供。