SQL慢查询优化提示词生成：双方向对比解析

处理慢查询时，核心动作是分析执行计划，定位全表扫描（type=ALL）或索引扫描且rows>10000的访问模式，同时排查Extra列是否出现Using filesort或Using temporary。设计联合索引与覆盖索引、合理设定前缀长度属于DBA的常规操作。但机械式建索引容易陷入“头痛医头”的误区。更精准的路径是：将一条慢查询拆分为两条不同维度的优化提示——一条专注执行计划与索引缺失，另一条侧重业务逻辑与数据访问模式重构。

方向一：基于执行计划诊断索引与结构缺陷

该提示词策略如下：让Claude先模拟EXPLAIN输出关键瓶颈，再据此生成索引创建指导。具体分三步实施：

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

第二步：要求Claude提取执行计划中【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张表，提示词中必须出现“拆解为两阶段查询”字样。