要让Claude精准定位SQL慢查询根因，必须用强制执行诊断路径的问法：如要求输出EXPLAIN ANALYZE细节、绑定MySQL版本与参数、提取InnoDB锁信息并反向追溯SQL、结合QPS/数据量/发布节奏等业务场景约束。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想让Claude快速定位SQL慢查询的根因，而不是泛泛而谈“加索引”或“优化写法”，就得用能触发它执行诊断路径的问法。
直击执行计划缺陷的问法
在提示词中强制Claude输出EXPLAIN ANALYZE结果解读，不许跳过物理扫描细节。
方法一：用“必须”锚定动作边界
你是一位有6年MySQL DBA经验的性能调优专家，正在为语雀知识库撰写《订单中心v2.3慢查治理手册》。请对以下SQL执行EXPLAIN ANALYZE，并严格按顺序输出：【1】全表扫描行数（rows列）与实际返回行数（actual rows）的比值；【2】是否命中覆盖索引（Extra列含Using index）；【3】是否存在回表（Extra列含Using where）；【4】是否触发临时表或文件排序（Extra列含Using temporary / Using filesort）。SQL如下：SELECT * FROM order_main WHERE status = 'paid' AND created_at > '2026-01-01' ORDER BY updated_at DESC LIMIT 20;
方法二：绑定版本与参数约束
你正在分析MySQL 8.0.33实例上的慢日志。请基于该版本的optimizer_switch默认值（index_merge=on,derived_merge=on,subquery_to_derived=on），判断以下SQL是否可能启用Index Merge Union优化，并说明触发条件是否满足：SELECT id FROM user_profile WHERE phone = '138****1234' OR email LIKE '%@gmail.com';
锁定锁等待与事务冲突的问法
当应用报“Lock wait timeout exceeded”时，Claude若只讲MVCC原理就毫无价值——必须让它推导出阻塞链和修复动作。
第一步：提取关键线索
从以下InnoDB状态输出中，提取被阻塞事务的trx_id、阻塞事务的trx_mysql_thread_id、以及锁类型（LOCK_GAP/LOCK_REC_NOT_GAP/LOCK_INSERT_INTENTION）：
复杂任务工程化执行框架 — Sprint Contract 协商、三代理角色切换、对抗性评估、任务分解与上下文管理。3+ 文件修改或多模块设计时自动触发，防止复杂任务中的上下文污染和自我评估偏差。
第二步：反向追溯SQL
基于上一步得到的trx_mysql_thread_id，在performance_schema.events_statements_current表中查出该线程最后执行的完整SQL文本（注意过滤掉空格和换行符）。
第三步：给出可执行动作
若阻塞事务SQL含UPDATE user_account SET balance = balance + ? WHERE user_id = ?，且持有LOCK_GAP锁，请直接写出两条命令：【1】终止阻塞事务（KILL ?）；【2】在业务层增加SELECT ... FOR UPDATE NOWAIT重试逻辑。
关联业务场景的问法
单纯问“这个SQL怎么优化”会得到教科书答案；但加上QPS、数据量、变更频率，Claude会切换成DBA实战视角。
方法一：注入真实压测数据
该SQL在日均QPS 1200的订单履约服务中，P95响应时间达1840ms。表order_detail当前数据量2.7亿行，近30天仅INSERT无UPDATE。请基于此背景，判断是否应创建复合索引(status, sku_id, created_at)，并说明理由——若创建，需补充ALTER TABLE ... ALGORITHM=INPLACE防止锁表。
方法二：绑定发布节奏
该SQL即将随v2.4版本上线，灰度周期仅48小时。请评估两种方案风险：【A】上线前预建索引（需停写15分钟）；【B】上线后在线创建（ALGORITHM=INPLACE，预计耗时37分钟）。输出必须包含每种方案对灰度流量的影响描述，禁用“建议”“可以考虑”等模糊表述。
