write-query

/write-query - 编写优化的 SQL

如果你看到不熟悉的占位符，或需要确认哪些工具已连接，请参阅 CONNECTORS.md。

根据自然语言描述编写 SQL 查询，并针对你使用的具体 SQL 方言进行优化，遵循最佳实践。

用法

/write-query <description of what data you need>

工作流

1. 理解需求

解析用户的描述，识别以下内容：

• 输出列：结果应包含哪些字段？
• 过滤条件：哪些条件会限制数据（时间范围、分群、状态）？
• 聚合：是否需要 GROUP BY 操作、计数、求和、平均值？
• 关联：是否需要合并多个表？
• 排序：结果应如何排序？
• 限制：是否需要 Top-N 或抽样？

2. 确定 SQL 方言

如果尚不清楚用户使用的 SQL 方言，请询问：

• PostgreSQL（包括 Aurora、RDS、Supabase、Neon）
• Snowflake
• BigQuery（Google Cloud）
• Redshift（Amazon）
• Databricks SQL
• MySQL（包括 Aurora MySQL、PlanetScale）
• SQL Server（Microsoft）
• DuckDB
• SQLite
• 其他（请说明具体类型）

在同一会话中，后续查询应记住该方言。

3. 探索 Schema（如果已连接数据仓库）

如果已连接数据仓库 MCP 服务：

1. 根据用户的描述搜索相关表
2. 检查列名、类型和关系
3. 检查会影响性能的分区或聚簇键
4. 查找可能简化查询的预构建视图或物化视图

4. 编写查询

遵循以下最佳实践：

结构：

• 当查询包含多个逻辑步骤时，使用 CTE（WITH 子句）提高可读性
• 每个逻辑转换或数据源使用一个 CTE
• 为 CTE 使用具有描述性的名称（例如 daily_signups、active_users、revenue_by_product）

性能：

• 生产查询中切勿使用 SELECT *，只指定需要的列
• 尽早过滤（尽可能将 WHERE 子句下推到基础表附近）
• 可用时使用分区过滤器（尤其是日期分区）
• 对于结果集较大的子查询，优先使用 EXISTS 而不是 IN
• 使用恰当的 JOIN 类型（当 INNER JOIN 正确时，不要使用 LEFT JOIN）
• 当 JOIN 或窗口函数可以实现时，避免使用相关子查询
• 注意关联爆炸（多对多）问题

可读性：

• 对于不明显的逻辑，添加注释说明"为什么"
• 使用一致的缩进和格式
• 为表使用有意义的简短别名（而不仅仅是 a、b、c）
• 每个主要子句单独占一行

方言特定优化：

• 应用方言特定的语法和函数（详见 sql-queries 技能）
• 使用与方言相符的日期函数、字符串函数和窗口语法
• 说明方言特有的性能特性（例如 Snowflake 聚簇、BigQuery 分区）

5. 呈现查询

提供：

1. 完整查询，放在带语法高亮的 SQL 代码块中
2. 简要说明每个 CTE 或部分的作用
3. 性能说明（如相关），例如预期成本、分区使用情况、潜在瓶颈
4. 修改建议——如何调整以适应常见变体（不同时间范围、不同粒度、附加过滤条件）

6. 提议执行

如果已连接数据仓库，提议运行该查询并分析结果。如果用户想自行运行，查询可直接复制粘贴使用。

示例

简单聚合：

/write-query Count of orders by status for the last 30 days

复杂分析：

/write-query Cohort retention analysis -- group users by their signup month, then show what percentage are still active (had at least one event) at 1, 3, 6, and 12 months after signup

性能关键型：

/write-query We have a 500M row events table partitioned by date. Find the top 100 users by event count in the last 7 days with their most recent event type.

小贴士

• 预先说明你的 SQL 方言，以便立即获得正确的语法
• 如果你知道表名，请一并提供——否则 Claude 会帮你查找
• 说明你是否需要查询具备幂等性（可安全重复运行），还是一次性查询
• 对于周期性查询，如果需要按日期范围参数化，请说明