后端接口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）做自动化格式校验。
维护一份“高频查询模板”，把常用提示词固化，减少重复编写工作。