/write-query - 编写优化的 SQL

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

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

用法

/write-query <你需要的数据的描述>

工作流程

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. 发现模式（如果数据仓库已连接）

如果数据仓库 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 按状态统计过去 30 天的订单数量

复杂分析：

/write-query 群组留存分析——按注册月份分组用户，然后显示在注册后 1、3、6 和 12 个月仍活跃（至少有一次事件）的百分比

性能关键型：

/write-query 我们有一个 5 亿行按日期分区的事件表。找出过去 7 天内事件数排名前 100 的用户及其最新事件类型。

技巧

• 提前说明你的 SQL 方言，以便立即获得正确的语法
• 如果你知道表名，请包含它们——否则 Claude 会帮助你找到它们
• 指定查询是否需要幂等（可安全重新运行）或一次性使用
• 对于定期查询，说明是否需要为日期范围参数化