要精准定位数据库慢查询原因，必须提供完整SQL、EXPLAIN执行计划及表结构与数据分布信息；否则模型只能泛泛而谈，无法给出有效诊断。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让通义千问精准定位数据库慢查询的根本原因，必须在提示词中明确给出可分析的上下文，不能只问“为什么慢”。缺少执行计划、SQL语句结构、表数据量或索引状态时，模型只能泛泛而谈锁、连接数或硬件问题，实际排查毫无价值。
提供完整可分析的SQL执行上下文
第一步：粘贴完整的慢SQL语句，包括WHERE、JOIN、子查询、ORDER BY和LIMIT部分。不要截断，也不要改写成伪代码——【改写后的SQL会丢失真实谓词选择率和执行路径特征】。
第二步：附上该SQL在数据库中实际执行的EXPLAIN（MySQL）或EXPLAIN ANALYZE（PostgreSQL）输出结果。文本格式即可，无需截图。没有这个，就等于让医生不看CT片就判断肿瘤位置。
第三步：说明该表的行数（如“user_order表约1200万行”）、主键字段、已建索引（用SHOW CREATE TABLE或\d+输出），以及WHERE条件中涉及字段的数据分布特征（例如“status字段只有3个枚举值，但95%是‘pending’”）。
区分不同慢因类型的提问方式
方法一：怀疑索引失效 → 直接问：“WHERE条件用了order_time > '2024-01-01' AND status = 1，但EXPLAIN显示type=ALL，为什么没走order_time索引？”
方法二：JOIN导致膨胀 → 描述现象：“LEFT JOIN后返回行数比左表多17倍，EXPLAIN里rows列左表8万、右表2300万，怎么优化关联逻辑？”
方法三：排序或分页瓶颈 → 明确指出：“ORDER BY create_time DESC LIMIT 10 OFFSET 100000，响应时间从20ms跳到3.2s，是否必须加复合索引？”
避免无效提问的典型错误
不要只写“这个SQL很慢，请优化”，这等于把整本《数据库内核原理》扔给模型去翻。
不要用“大概”“可能”“好像”描述现象，比如“好像没走索引”——请直接贴EXPLAIN里的key字段值。
不要脱敏过度：把t_user表改成t_xxx、把real_name字段改成f1，模型无法判断是否涉及函数索引或前缀索引限制。
