Workflows
保存和复用分析
一次有价值的查询不应该只停留在某个临时标签页里。Dory 的 Saved Queries 可以把 SQL、业务问题和分析上下文保存下来，让个人和团队后续更容易复用。
什么时候保存分析
- 查询会被反复运行。
- 查询回答了稳定的业务问题。
- 查询经过了调优或排错。
- 查询会用于图表、周报或监控。
- 团队成员需要参考这条 SQL。
1. 保存前先清理 SQL
保存之前，建议先做整理：
- 删除无用临时代码。
- 保留必要注释。
- 明确时间范围或参数位置。
- 使用清晰列别名。
- 确认查询只包含需要共享的逻辑。
不建议保存一堆实验性 SQL 混在同一个查询里。
2. 使用业务化命名
好的名称应该描述结果，而不是描述表。
| 不推荐 | 推荐 |
|---|---|
orders query | 最近 30 天每日订单数 |
user sql | 活跃用户 Top 城市 |
debug | 支付失败订单排查 |
clickhouse test | ClickHouse 慢查询 Top 50 |
3. 写清楚描述和假设
描述里建议包含：
- 业务问题。
- 指标定义。
- 时间范围。
- 过滤条件。
- 去重逻辑。
- 适用数据库或连接。
- 后续图表用途。
示例：
统计最近 30 天每日订单数，仅包含 paid 状态订单。用于运营日报趋势图。按 created_at 日期聚合，不做用户去重。4. 用文件夹组织查询
建议按团队使用方式组织：
- 业务域：Orders、Users、Payments、Events。
- 使用场景：Dashboards、Debugging、Weekly Reports。
- 环境：Production Readonly、Staging、Demo。
- 数据库类型：ClickHouse、PostgreSQL、MySQL。
结构越清晰，Saved Queries 越像团队知识库，而不是个人草稿箱。
5. 定期复查和归档
保存查询会不断增加，需要定期维护：
- 删除或归档失效查询。
- 更新字段变更后的 SQL。
- 合并重复查询。
- 标记仍在使用的核心查询。
- 将高风险查询改成只读或加上限制条件。
常见问题
什么 SQL 不适合保存？
临时实验、未验证口径、含敏感信息、可能误操作生产库或依赖个人环境的 SQL 都不适合直接保存。
Saved Queries 可以替代文档吗？
不能完全替代。Saved Queries 适合保存可执行 SQL，复杂业务口径仍建议在团队文档中说明，并从文档链接到查询。
如何让团队更容易复用？
使用统一命名、清晰描述、文件夹分类，并在 SQL 中保留必要注释。
下一步
- 从 使用 Ask AI 生成 SQL 生成查询。
- 用 Build Charts from SQL 整理图表输出。
- 查看 Saved Queries 了解功能细节。
这篇文档有帮助吗？