SQL慢查询优化：用Gemini写出精准提示词与目标用户定位

写SQL慢查询优化Prompt时，最常见的失误是什么？就是把目标用户画像定义得过于模糊。像Gemini这类模型默认会以“全能DBA”的视角输出建议，但现实中，后端开发、运维工程师、产品经理各自的操作权限和系统边界差异极大。如果这一步没界定清楚，后续所有优化建议都可能无法落地执行。

那么，具体该怎么写？

先锁定目标用户角色

第一句就得明确角色标签。例如“本Prompt面向【Java后端开发人员】”，或“本Prompt面向【数据库运维工程师】”。切忌使用“相关人员”“使用者”这类看似包容、实则空泛的表述。角色一旦定位错误，整个思路就会跑偏：面向初级开发给出索引优化，却推荐了只有DBA才能执行的DDL命令；面向业务分析师提SQL改写，却要求他手动调整复杂JOIN逻辑——这一步错了，后续所有努力都白费。

说明该用户的技术权限与上下文约束

光有角色还不够，还得把“他手里握有哪些资源”交代清楚。这里提供几种写法：

你可以用短句枚举关键事实：

【数据库运维工程师】：拥有ALTER TABLE权限，但无线上服务发布权限；所在环境使用MySQL 8.0.33，主从延迟容忍度≤100ms。

【Java后端开发人员】：只能修改Mapper XML或MyBatis注解SQL，无法调整数据库表结构；日志中已确认该SQL来自订单履约服务，QPS峰值为230。

【数据产品经理】：不直接操作SQL执行，仅查看DataStudio中查询耗时告警；需要向运营团队解释“为什么筛选近7天订单变慢了”，必须避免技术术语。

把用户目标动作嵌入问题描述

接下来是最关键的一步：将“这个人接下来要执行的具体操作”写入Prompt。

第一步：明确写出用户接下来的核心动作。 例如：“我是一名刚接手老系统的Java后端开发，现在需要上线一个修复补丁，要求在不改表结构、不加索引的前提下，把这条SQL响应时间从8.2s压到≤500ms。”

第二步：指出他能操作的具体载体。 这一步必须精确到文件路径或界面位置。是修改order-service模块下的OrderQueryMapper.xml第47行？还是调整Flink SQL作业中的维表JOIN逻辑？或是替换QuickSight仪表板里的自定义SQL字段？描述越具体，模型给出的方案越能直接落地。

第三步：标注他不可触碰的边界。 例如“禁止修改user_info表字段类型”“不允许在凌晨2点执行OPTIMIZE TABLE”“不能新增字段供前端展示”。这些限制若不写进Prompt，Gemini大概率会推荐一个看似完美、但实际上无法落地的方案。

归根结底，写好SQL优化Prompt的核心，就是把“那位用户”的真实处境完整还原：他拥有什么权限，能在哪个文件中修改代码，什么操作绝对禁止。把这些信息交代清楚，Gemini给你的建议才不会偏离实际轨道。