请基于以下EXPLAIN输出分析性能瓶颈并推荐具体索引。Kimi可精准识别缺失索引、复合索引顺序及覆盖索引机会，并建议验证选择性后再建索引；还可重写低效SQL，如将函数查询转为范围查询。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要在开发或运维过程中快速定位MySQL慢查询瓶颈，并获得可直接落地的优化建议，而不是泛泛而谈的理论或需要反复试错的手动调优。
用Kimi分析EXPLAIN输出并给出索引建议
将MySQL执行计划的EXPLAIN结果完整复制进Kimi对话框，开头明确提示“请基于以下EXPLAIN输出分析性能瓶颈并推荐具体索引”。
确保粘贴的是实际执行的EXPLAIN SELECT语句结果，不是截图文字或手动重写的简化版——Kimi对字段名、type值（如ALL/eq_ref）、rows估算数、Extra中Using filesort等关键词高度敏感。
等待Kimi返回结构化建议，它通常会指出：哪张表缺失驱动列索引、复合索引应按什么顺序排列、是否可通过覆盖索引避免回表。
执行建索引命令前，先用【SELECT COUNT(*) FROM 表名 WHERE 关键条件】验证该条件的选择性是否足够高（建议>0.1），否则建索引反而拖慢写入。
让Kimi重写低效SQL语句
方法一：直接提交原始SQL + 当前执行耗时 + 表数据量级（例如“users表500万行，这条SELECT *查询平均3.2秒”）。
方法二：附上SHOW CREATE TABLE的输出，Kimi能结合字段类型、主键、现有索引判断改写可行性。
使用 Moonshot Kimi API 的 $web_search 内置工具进行联网搜索。当需要进行网络搜索获取实时信息时使用，支持中文和英文搜索查询。需要配置 MOONSHOT_API_KEY。
Kimi常将子查询自动转为JOIN，把WHERE MONTH(create_time)=5改为WHERE create_time >= '2026-05-01' AND create_time
注意：若原SQL含用户变量（@var）或自定义函数，Kimi可能无法安全重写，需人工核验逻辑一致性。
用Kimi诊断慢查询日志片段
第一步：从slow.log中截取一段典型慢查询记录，包含# Time、# User@Host、Query_time、Lock_time、Rows_examined及完整SQL。
第二步：粘贴到Kimi，指令为“请分析此慢查询日志条目，指出最可能的优化方向（索引/SQL/配置）并说明依据”。
第三步：重点看Kimi是否识别出Rows_examined远大于Rows_sent（比如扫描200万行只返回100行），这直接指向【缺少有效过滤索引或WHERE条件未走索引】。
第四步：若Kimi建议调整long_query_time，需同步检查当前MySQL的profiling是否开启——因为仅靠慢日志无法反映1秒内高频次小查询的累积压力。
