在cursor中精准触发sql优化建议需三步：先锁定角色权限（如无ddl权限、仅能查指定视图），再明确业务场景与时效要求，最后提供真实表结构、字段业务含义及可操作范围限制。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要在Cursor中精准触发数据库SQL优化建议，但模型常泛泛而谈索引、执行计划或给出无法落地的DDL操作，根本原因是提示词没锁死角色、权限、表结构和业务约束。
锁定身份与权限边界
第一步：在提示词最开头写明你的真实角色和数据权限。【我是电商公司用户增长组的运营分析师，无数据库DDL权限，不能新建索引、修改表结构或访问原始日志表，仅能查询已授权视图，包括v_user_event_summary、v_order_daily_agg】。这句必须前置——Cursor若不知道你连CREATE INDEX都执行不了，后续所有“加复合索引”的建议全是废纸。
第二步：紧跟着说明该SQL服务的具体业务动作。例如：“此SQL用于每日早10点推送‘7日内未下单高潜用户’名单，需在2分钟内返回≤5000条记录，超时将导致企业微信自动推送中断。”不写清时效要求，Cursor可能推荐内存排序方案——而你的生产环境单节点内存只有4GB，根本跑不动。
提供真实表结构上下文
直接粘贴目标视图的字段定义或CREATE VIEW语句。比如：CREATE VIEW v_user_event_summary AS SELECT user_id, event_type, created_at, device_type FROM raw_events WHERE event_type IN ('login', 'view_product', 'add_to_cart');。不提供这个，Cursor只能靠猜字段含义，常把device_type当成主键去JOIN。
对关键关联字段加一句说明：“v_user_event_summary.user_id 是主键，v_order_daily_agg.user_id 外键关联它”。否则模型可能用email字段去join，而email在v_order_daily_agg里根本不存在。
如果字段名有歧义，必须人工注入业务含义。例如表里有pay_amount、actual_amount、final_price三个数值字段，就写：“我要查用户实际支付的订单金额（即final_price字段，已扣除优惠券和平台补贴）”。【字段名本身不带业务含义，必须人工注入】。
Agents 正在你的整个代码库中处理越来越复杂、运行时间更长的任务。本次版本引入了新的 agent 框架改进，以实现更好的上下文管理，并在编辑器和 CLI 中带来了许多提升使用体验的修复。
限定优化动作类型
方法一：用分号分层声明可操作范围
“优化仅限以下三类操作：① 重写WHERE条件（如拆分OR、用IN替代模糊匹配）；② 调整JOIN顺序或改用EXISTS替代LEFT JOIN；③ 在SELECT字段中删除非必要列（尤其禁止SELECT *）；其他任何涉及DBA协作的操作均不接受。”
方法二：用否定式排除干扰项
【禁止建议任何需要ALTER TABLE、CREATE INDEX、修改统计信息或重启服务的操作】。这条必须写，否则Cursor默认进入DBA模式，输出一堆你根本没法执行的命令。
方法三：给Cursor一个硬性判断锚点
“如果某条优化建议执行后仍无法在15秒内完成，即使语法更简洁，也视为不可行。”
控制输出格式与字段来源
在提示词末尾明确要求：“只返回标准SQL语句，不解释，不加```sql代码块”。
追加约束：“所有字段必须来自上述提供的视图结构，禁止虚构字段名或表别名”。
如果涉及多表查询，加上：“使用显式JOIN语法，ON条件必须基于已知外键关系”。这三步能砍掉80%的“unknown column”报错——模型常默认用隐式逗号连接+WHERE关联，一旦字段名在多个视图中重复（比如两个视图都有user_id），就会报错。
