需要把自然语言数据需求转成优化 SQL 时：按方言生成…

把自然语言数据需求翻译成特定 SQL 方言的优化查询，尤其适合多 CTE、连接聚合、大分区表性能优化和方言语法获取。

适用场景

解决思路

1. 使用 `/write-query <description of what data you need>` 从自然语言描述生成 SQL 查询。
2. 理解请求时解析描述并识别：输出列、过滤条件（时间范围、分群、状态等）、聚合（GROUP BY、count、sum、avg）、连接（是否需要合并多表）、排序、限制（top-N 或采样）。
3. 如果还不知道用户的 SQL 方言，询问其使用哪种。
4. 可选方言包括 PostgreSQL（包括 Aurora、RDS、Supabase、Neon）、Snowflake、BigQuery（Google Cloud）、Redshift（Amazon）、Databricks SQL、MySQL（包括 Aurora MySQL、PlanetScale）、SQL Server（Microsoft）、DuckDB、SQLite、Other（询问具体信息）。
5. 在同一会话中记住该方言，后续查询继续使用。
6. 如果连接了数据仓库 MCP server，先发现 schema：根据用户描述搜索相关表。
7. 如果连接了数据仓库 MCP server，检查列名、类型和关系。
8. 如果连接了数据仓库 MCP server，检查影响性能的分区键或聚簇键。
9. 如果连接了数据仓库 MCP server，查找可简化查询的预构建视图或物化视图。
10. 写查询时，结构上在查询有多个逻辑步骤时使用 CTE（WITH 子句）提升可读性。
11. 每个逻辑转换或数据源使用一个 CTE。
12. 用描述性名称命名 CTE（例如 `daily_signups`、`active_users`、`revenue_by_product`）。
13. 性能上，绝不在生产查询中使用 `SELECT *`，只指定需要的列。
14. 尽早过滤：把 WHERE 子句尽量下推到基础表附近。
15. 可用时使用分区过滤器，尤其是日期分区。
16. 对于大结果集子查询，优先使用 `EXISTS` 而不是 `IN`。
17. 使用合适的 JOIN 类型，不要在应该用 INNER JOIN 时使用 LEFT JOIN。
18. 当 JOIN 或窗口函数可以完成时，避免相关子查询。
19. 注意多对多连接导致的膨胀连接（exploding joins）。
20. 可读性上，为非显然逻辑添加注释解释“为什么”。
21. 使用一致的缩进和格式。
22. 用有意义的短别名给表命名，不要只用 `a`、`b`、`c`。
23. 每个主要子句单独占一行。
24. 方言特定优化：应用方言特定的语法和函数（详见 `sql-queries` 技能）。
25. 使用与方言匹配的日期函数、字符串函数和窗口语法。
26. 标注任何方言特定的性能特性（例如 Snowflake clustering、BigQuery partitioning）。
27. 展示查询时，在带语法高亮的 SQL 代码块中提供完整查询。
28. 展示查询时，简要解释每个 CTE 或部分做什么。
29. 展示查询时，如相关则提供性能说明（预期成本、分区使用、潜在瓶颈）。
30. 展示查询时，提供修改建议：如何调整常见变化（不同时间范围、不同粒度、额外过滤）。
31. 如果连接了数据仓库，询问是否要运行查询并分析结果。
32. 如果用户想自己运行，确保查询已准备好可复制粘贴。
33. 提前说明 SQL 方言，以便立即获得正确语法。
34. 如果知道表名就提供；否则让 Claude 帮助查找。
35. 说明查询是否需要幂等（可安全重跑）还是一次性。
36. 对于重复查询，说明是否应参数化日期范围。

适用边界 · 注意事项

• 当任务不是把数据需求写成 SQL 查询，而是其他类型开发或非查询数据分析时，不适用。
• 如果没有可连接的数据仓库且用户无法提供表/schema 信息，生成查询只能基于假设，准确性受限。
• 如果用户既不确定 SQL 方言也不愿指定，就难以应用方言特定语法和优化。