必须用错误日志锚定阻塞链，禁用通用优化词库，并用“因……”结构描述具体缺陷，否则codeium将返回泛化建议而非精准修复。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
用Codeium诊断SQL性能问题时，提示词反复生成“添加索引”“避免SELECT *”“拆分大事务”等泛化建议，根本无法定位你线上慢查的真实瓶颈——这是因为提示词没锁死执行路径，让AI在通用知识库中随机采样。
第一步：用错误日志锚定真实缺陷
打开SQL Server Management Studio的活动监视器或PostgreSQL的pg_stat_statements视图，复制最近一次超时查询的完整错误日志（含时间戳、会话ID、等待类型）。【必须包含WAIT_INFO或Blocking_Session_ID字段】，没有这些字段，Codeium会默认走教科书式优化路径。
把错误日志粘贴到Codeium聊天框第一行，后面紧跟：“请只分析此日志暴露的阻塞链，不提索引、统计信息、参数嗅探等无关项。”
第二步：强制输出可验证动作链
方法一：按行号定位→复现→修复三步闭环
① 在错误日志里找到“wait_type = LCK_M_U”那一行，记下第17行的UPDATE语句。
② 补充最小复现输入：“EXEC usp_UpdateInventory @sku = 'A1023', @qty = -5”
③ 输出唯一修复代码：“WITH (UPDLOCK, ROWLOCK) ——加在UPDATE语句FROM子句后”
方法二：用数据库原生命令反向验证
直接写：“用DBCC INPUTBUFFER(12345)查出被阻塞会话的原始语句，再用sp_whoisactive确认blocking_session_id=0的源头SQL，最后只输出该源头SQL的第3行修改建议。”
这一步操作起来很简单，直接把DBCC命令和sp_whoisactive结果粘进去就行。但【若未提供会话ID，Codeium将跳过所有步骤】，它不会自行猜测或补全。
第三步：禁用通用优化词库
在提示词最开头第一行，必须粘贴：
【禁止使用“添加索引”“避免SELECT *”“拆分大事务”“检查统计信息”“启用查询计划”等12个通用短语】
Codeium会把前置指令当硬约束，后加的禁用词表基本无效。如果跳过这句，后续所有提示都白搭——它默认启用DBA培训教材话术库。
再补一句具体缺陷描述：“当前usp_GetOrderList在@status = 'shipped'时扫描全表，因status字段无非空约束且未建过滤索引。”
这句必须用“因……”结构，Codeium才能识别因果链。写成“status字段缺少索引”会被归类为通用建议，直接触发禁用词库。
