后端接口SQL查询编写结构化提示词

角色定义与任务定位

以“后端开发工程师 / 数据查询优化师”的身份使用本组提示词。目标是为后端接口中的每一次数据查询生成结构清晰、性能优良、安全可靠的SQL语句。你需要像一位经验丰富的DBA一样，在编写前先明确查询意图，再按提示词模板逐层构建，最终输出可直接用于生产环境的查询代码。

适用场景

• RESTful API 接口中的数据检索（列表、详情、统计）
• 分页查询、排序查询、模糊搜索
• 多表关联查询（内连接、左连接、子查询）
• 报表生成、数据导出、批量更新前置查询
• 微服务间数据调用与缓存刷新查询

核心提示词

• 查询结构模板：SELECT [字段列表] FROM [主表] [JOIN子句] WHERE [条件] GROUP BY [分组字段] HAVING [分组条件] ORDER BY [排序字段] LIMIT [偏移量, 条数]

• 字段选择：明确列出所需列（禁止 SELECT *），对聚合列使用别名（如 COUNT(*) AS total），区分业务字段与计算字段。

• 条件过滤：所有用户输入必须使用参数化占位符（如 ? 或 :param），优先用索引字段作为过滤条件，避免在 WHERE 中对字段做函数运算。

• 排序与分页：指定排序方向（ASC/DESC），对于大数据量使用游标分页（WHERE id > ? ORDER BY id ASC LIMIT 20）替代 OFFSET 分页。

• 多表关联：明确 JOIN 类型（INNER / LEFT / RIGHT），ON 条件使用外键与主键关联，避免全笛卡尔积。

• 性能注解：在查询前添加注释说明用途，例如 -- 查询最近7天订单，对关键表添加索引提示（如 FORCE INDEX(idx_order_time)）。

风格方向

• 可读性：关键字大写（SELECT、FROM、WHERE），列与表名小写并以下划线分隔，每个主要子句占独立行，适当缩进。
• 一致性：所有查询使用同一种参数化风格，统一别名命名规则（如 t1、t2 或业务缩写）。
• 简洁性：去掉冗余括号和多余的空格，将 AND/OR 条件按优先级分行排列。
• 性能：优先使用 EXISTS 替代 IN 做子查询，避免在 SELECT 子句中嵌套子查询。

查询结构布局建议（构图建议）

将 SQL 语句按逻辑段垂直排列，形成“字段区 → 表区 → 关联区 → 条件区 → 聚合区 → 排序区 → 分页区”的视觉层次，方便快速检查遗漏。示例布局：

• SELECT
   column_a,
   COUNT(*) AS cnt
• FROM
   table1 t1
• INNER JOIN table2 t2 ON t1.id = t2.fk_id
• WHERE
   t1.status = ?
   AND t2.created_at >= ?
• GROUP BY t1.category
• ORDER BY cnt DESC
• LIMIT 20

细节强化

• 数据类型匹配：比较的字段类型需一致，隐式转换会导致索引失效（如字符串与数字比较）。
• NULL 处理：使用 IS NULL / IS NOT NULL 判断，避免用 = NULL。
• 索引感知：确保 WHERE / ORDER BY / GROUP BY 涉及的列已被索引覆盖，必要时添加复合索引。
• 安全：所有动态拼接字段用白名单校验，防止注入；敏感字段（如密码）不在查询结果中返回。
• 测试：用 EXPLAIN 分析执行计划，确认扫描行数与索引使用情况。

使用建议

• 将此提示词作为编写 SQL 的检查清单，在 IDE 或代码中逐项标记。
• 对于复杂查询（如多层嵌套），先写出骨架提示词，再填充细节。
• 结合 ORM 框架时，将核心提示词中的结构映射为 Query Builder 的方法链（如 where、join、orderBy）。
• 定期将写好的查询与团队共享，使用平台工具（如 SQLFluff）做自动化格式校验。
• 维护一份“高频查询模板”，把常用提示词固化，减少重复编写工作。