在日常数据库性能调优过程中，面对一条慢查询，常规操作往往是打开执行计划，定位那些“type=ALL”或“type=index且rows>10000”的表，并检查Extra列是否出现“Using filesort”或“Using temporary”这两个关键风险信号。针对此类情况，通常需要设计联合索引与覆盖索引，并合理设置前缀长度——这是数据库管理员最基础的索引优化动作。然而，如果仅机械地创建索引，有时反而会陷入“头痛医头”的片面困境。更高效的策略是：将一条慢查询拆解为两个不同维度的优化提示词——一个聚焦执行计划与索引缺失分析，另一个侧重业务逻辑与数据访问模式的重构。

方向一：基于执行计划反推索引与结构瓶颈

这条提示词的思路是：让Claude先模拟EXPLAIN输出并标记关键瓶颈点，再据此生成索引创建指导。具体可分为三个步骤：

第一步：将原始SQL粘贴至Prompt，并附加指令：“请基于MySQL 8.0默认优化器行为，模拟该SQL最可能的EXPLAIN结果，重点关注type、key、rows、Extra字段。”

第二步：要求它提取执行计划中【type=ALL或type=index且rows>10000】的表，以及【Extra包含Using filesort或Using temporary】的操作节点。

第三步：使用提示词“请生成一条用于指导DBA创建高效索引的指导词”收尾，限定输出为单句，不说明、不举例，且必须包含“联合索引”“覆盖索引”“前缀长度”三个关键词中的至少两个。

方向二：从业务语义重构数据访问路径

这条提示词不关注执行计划，仅分析SQL的字面含义与常见业务场景。有两种实现方法：

方法一：让Claude识别SQL中的WHERE条件字段与SELECT字段，判断是否存在“高频筛选但低频返回”的现象——例如WHERE使用user_id=?但SELECT返回了blob字段或超过15个列。

方法二：强制假设该SQL每天被调用超过5000次，且90%的请求只关心最近7天的数据，然后生成提示词：“请重写该查询，使其自然地利用按时间分区的物理结构，避免全表扫描，同时保持语义等价。”

注意：若原始SQL包含子查询或JOIN多于3张表，提示词中必须出现“拆解为两阶段查询”字样。