云原生平台SQL查询编写专业版提示词

角色定义与任务定位
请以“云原生数据库架构师”或“资深数据平台工程师”的身份，运用本方案。您的核心目标是：为在Kubernetes、服务网格、微服务等云原生环境中运行的数据平台，构思并生成精准、高效、可维护且符合云原生最佳实践的SQL查询语句。这不仅是编写代码，更是为动态、可扩展的云环境设计数据访问蓝图。
适用场景

为运行在云原生平台（如基于K8s的数据库服务）上的应用程序编写核心业务查询。
设计用于跨微服务或多租户数据库的数据聚合与分析查询。
优化现有查询，使其适应弹性扩缩容、服务发现等云原生特性。
创建数据看板、监控告警所需的查询脚本，并与Prometheus、Grafana等云原生观测工具联动。
编写用于CI/CD流水线中的数据验证、迁移回滚的SQL脚本。

核心提示词
以下提示词组合可直接用于您的文本生成工具，以产出专业SQL查询。请根据具体需求替换 `{ }` 中的变量。

基础查询构造： “作为云原生平台的数据工程师，请编写一个用于查询 `{表名}` 的SQL语句，核心目标是 `{查询目标，如：统计今日各服务Pod的异常日志数量}`。需考虑多租户隔离（通过 `tenant_id` 字段），并按时间分区（`event_time` 字段）进行高效过滤。”
性能与扩展性优化： “生成一个针对微服务链路追踪数据的聚合查询。要求：关联 `span_info` 和 `service_metadata` 表，计算每个服务的平均响应延迟与P99延迟，结果需适配横向扩展的只读副本，并提示可能用到的索引策略（如对 `trace_id`, `start_time` 创建联合索引）。”
运维与观测集成： “设计一个SQL查询，从集中式日志表中提取最近1小时内错误级别为‘ERROR’的条目，并按照所属的Kubernetes命名空间（`namespace` 字段）和部署（`deployment` 字段）进行分组统计，输出格式需便于导入到告警系统或Grafana进行可视化。”

风格方向

技术严谨性： 语句结构清晰，显式定义JOIN条件，避免SELECT *，明确列出字段。
云原生意识： 在注释或结构设计中体现对资源标签（Labels）、注解（Annotations）、服务发现、配置管理的考量。
声明式倾向： 在复杂查询中，通过CTE（公共表表达式）或视图使逻辑更模块化，类似于声明式编排。
可移植与无状态： 减少对数据库特定函数或会话状态的依赖，强调查询本身的可重复执行性。

构图建议（逻辑结构）
将SQL查询的编写视为构建一个清晰的数据流水线：

顶层架构： 优先定义查询的最终输出目标和使用的数据源（来自哪个服务、哪个逻辑数据库）。
中间层处理： 使用WITH子句（CTE）将复杂逻辑分解为多个步骤，如数据清洗、维度关联、中间指标计算。
底层连接： 明确表之间的关联关系，优先使用INNER JOIN并指定关联键，考虑云环境下可能的网络延迟与分区策略。
输出过滤与排序： 将WHERE条件、GROUP BY、HAVING和ORDER BY作为最终的数据塑形环节，确保结果集精简、有序。

细节强化

资源标识： 在查询条件或结果中，融入 `cluster_name`、`node_name`、`pod_id`、`container_id` 等云原生资源标识符。
时间处理： 统一使用UTC时间戳，并提供基于 `event_time` 分区键的高效时间范围查询示例。
弹性考量： 在注释中提示，当查询超时或资源不足时，可考虑的策略（如设置查询超时、使用分页LIMIT OFFSET）。
安全与隔离： 强调在查询中必须包含租户隔离条件（如 `WHERE tenant_id = ?`），或使用行级安全策略。

使用建议

将上述“核心提示词”直接复制到支持长文本生成的AI工具中，替换变量并执行，可获得初步的SQL草稿。
生成后，务必结合具体数据库（如PostgreSQL on Cloud SQL, CockroachDB, TiDB）的方言和特性进行微调。
在团队内部，可将本方案中的“风格方向”和“细节强化”点作为代码审查（Code Review）中SQL部分的标准检查项。
对于极度复杂的查询，建议采用“构图建议”中的分层方法，分步生成并组合，确保逻辑正确性与可读性。