name: data-write-query description: 为您的SQL方言编写优化的SQL，遵循最佳实践
编写SQL查询
如果您看到不熟悉的占位符或需要检查连接了哪些工具，请询问可用的集成。
根据自然语言描述编写SQL查询，针对您的特定SQL方言优化并遵循最佳实践。
用法
您可以请求编写SQL查询（例如，“编写查询以统计订单”或“获取前10名用户”）。
参数
description— 描述您需要的数据和业务逻辑
工作流程
1. 理解请求
解析用户的描述以识别：
- 输出列：结果应包含哪些字段？
- 筛选条件：哪些条件限制数据（时间范围、细分、状态）？
- 聚合操作：是否有GROUP BY操作、计数、求和、平均值？
- 连接：是否需要组合多个表？
- 排序：结果应如何排序？
- 限制：是否有前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. 发现架构（如果数据仓库已连接）
如果数据仓库已连接：
- 基于用户描述搜索相关表
- 检查列名、类型和关系
- 检查影响性能的分区或聚类键
- 查找可能简化查询的预构建视图或物化视图
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） - 将每个主要子句放在单独的行上
方言特定优化：
- 应用方言特定语法和函数
- 使用方言适当的日期函数、字符串函数和窗口语法
- 注意任何方言特定的性能特性（例如，Snowflake聚类、BigQuery分区）
5. 呈现查询
提供：
- 完整查询，在SQL代码块中带有语法高亮
- 简要解释每个CTE或部分的作用
- 性能说明（如果相关：预期成本、分区使用、潜在瓶颈）
- 修改建议 — 如何调整以适应常见变化（不同时间范围、不同粒度、额外筛选器）
6. 提供执行选项
如果数据仓库已连接，提供运行查询并分析结果的选项。如果用户想自己运行，查询已准备好复制粘贴。
提示
- 提前提及您的SQL方言以立即获得正确语法
- 如果您知道表名，包括它们 — 否则我会帮您找到
- 指定是否需要查询是幂等的（可安全重新运行）或一次性
- 对于重复查询，提及是否应参数化日期范围