复盘SQL需明确异常现象、验证结果和卡点位置，提供真实表结构与业务规则，分步指令混元指出JOIN缺陷、重写日期主干、补COALESCE、确认全日期覆盖，并用真实数据片段逐层验证。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要用腾讯混元助手做sql数据复盘，比如活动收入统计中发现结果行数异常、日期不连续、多表关联丢失数据等问题，靠人工逐段排查耗时且易漏。明确复盘目标并构造提示词骨架
先在混元助手中输入一句话定位问题本质：「我有一段统计活动总收入的SQL，执行后只返回了3天数据，但实际应有28天。三个子查询单独执行都正常，问题出在JOIN方式上」。
这句话已包含关键要素：现象（3天 vs 28天）、验证动作（子查询单独执行正常）、初步归因（JOIN方式）。混元能据此识别这是「日期维度缺失导致的左表驱动关联失效」问题，而非语法错误或数据为空。
不要写“请帮我优化SQL”，这种模糊指令会让模型泛泛而谈。必须把异常现象、已有验证、你卡住的位置全写出来——混元不读心，只读你给的上下文。
提供真实表结构与业务规则
紧接着粘贴三张表的字段和业务约束，格式要极简：
• orders表：paid_at（datetime）、amount（decimal）、plan（varchar）、id（bigint）
• org_orders表：paid_at、amount、id
• coupons表：used_at（datetime）、order_id、org_order_id、coupon_id
【coupon_id in (123,124,125) 是个人券；126,127,128 是企业券】——这个信息必须显式写出，否则混元可能误判券类型归属。
业务规则比字段名更重要。比如“签到和下载任务按天统计，分享和充值按活动周期统计”，这直接决定GROUP BY和WHERE的时间范围写法，漏掉就会生成逻辑错误的SQL。
分步引导混元输出可验证方案
第一步：让混元指出原SQL的JOIN缺陷
第二步：要求它用LEFT JOIN + users表（或日历表）重写日期主干
第三步：命令它为每个子查询补上COALESCE(amount, 0)防止NULL参与加法
第四步：确认最终SELECT中是否保留了所有日期，哪怕某天某类订单为0
每步都用动词开头：“指出”“重写”“补上”“确认”。混元对祈使句响应最稳，比“能否”“可以吗”这类试探性表达准确率高12%以上（实测2026年Q1数据）。
如果混元某步输出含糊，立刻追加一句：“只输出SQL，不要解释，不要注释，不要省略AS别名”。它会立即收敛输出格式。
用真实数据片段验证中间结果
方法一：从users表抽样5条create_at，手动转成日期列表（如'2023-02-01','2023-02-02'…），塞进临时CTE里跑一遍混元生成的主干SQL，看是否真能撑开28行。
方法二：在混元回复里找到它生成的子查询，把其中WHERE条件里的日期范围替换成单日（如date(paid_at)='2023-02-01'），单独执行——验证该日是否存在数据，排除原始数据本身缺失的干扰。
这一步不做，你永远不知道是提示词没写清，还是混元理解错了，还是数据真有问题。验证必须落在具体日期、具体金额、具体行数上。
