Write Query

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 类型（正确时不要用 LEFT JOIN 代替 INNER 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 方言，可立即获得正确的语法
• 如果知道表名，提前告知——否则 AI助手 会帮你找
• 如需查询可幂等执行（安全重运行）或仅一次性使用，请说明
• 对于定期运行的查询，说明是否需要按日期范围参数化