MySQL 慢查询优化提示词：慢查询日志分析 + 联合索引设计（最左前缀、覆盖索引、索引失效排查）
数据库 CPU 高、接口变慢，手里有慢查询日志或 pt-query-digest 的汇总时用：让 AI 从一批慢查询里找出最值得优化的几条，逐条看执行计划，设计能覆盖多条查询的联合索引，同时检查索引失效的写法和多余的索引。
通用大模型 对话模型通用
你是一名 MySQL 性能优化专家。请帮我分析慢查询并设计索引。 - MySQL 版本与存储引擎：[如 MySQL 8.0 InnoDB] - 慢查询日志或汇总报告（可以是 pt-query-digest 的输出，或若干条慢 SQL 及执行次数、平均耗时）： [粘贴慢查询] - 相关表的建表语句（含现有索引）和大致行数： [粘贴建表语句] - 相关 SQL 的 EXPLAIN 结果（如果有）： [粘贴执行计划] - 写入频率：[如订单表每秒写入 200 条] 分析步骤： 1. 排序：按「总耗时 = 平均耗时 × 执行次数」排出最值得优化的前 5 条，说明为什么先优化它们（一条执行一万次的 200 毫秒查询，往往比一条每天执行一次的 10 秒查询更值得优化）。 2. 逐条分析： - 读执行计划：访问类型、使用的索引、扫描行数、是否出现文件排序或临时表； - 指出慢的原因：没有可用索引、索引选择性差、索引失效、回表太多、深分页、查询了不需要的列。 3. 索引失效检查：对索引列使用函数或运算、隐式类型转换（如字符串字段和数字比较）、前导通配符的 LIKE、OR 连接了无索引的列、联合索引不满足最左前缀、范围条件之后的列无法继续使用索引。 4. 联合索引设计： - 字段顺序的依据：等值条件在前、范围条件在后、兼顾排序和分组； - 能否做成覆盖索引避免回表； - 尽量用一个索引覆盖多条查询，避免一条查询建一个索引； - 检查现有索引中被新索引覆盖的冗余索引，建议删除。 5. 写法优化：不改索引也能提升的地方，例如改写深分页、拆分 OR、避免查询全部列。 6. 上线方案：给出建索引语句；说明大表加索引对线上的影响，在线变更的方式和执行时间段建议；上线后如何对比效果。 所有结论基于我提供的信息，缺少执行计划时说明「需要 EXPLAIN 结果确认」，不要编造扫描行数。
高亮处换成你自己的内容：[如 MySQL 8.0 InnoDB]、[粘贴慢查询]、[粘贴建表语句]、[粘贴执行计划]、[如订单表每秒写入 200 条]
ChatGPT Plus 充值
已被复制 0 次
使用说明
怎么填变量：[相关表的建表语句] 必须包含现有索引，否则 AI 无法判断冗余索引，也可能建议一个已经存在的索引。[写入频率] 用来权衡索引数量：写入很频繁的表，每多一个索引都会拖慢写入。
常见坑：
- 一条慢查询建一个索引，几个月后表上有十几个索引，写入越来越慢，优化器还经常选错。设计索引要把同一张表上的多条查询放在一起考虑。
WHERE DATE(create_time) = '2026-10-01'这类写法会让索引失效，要改成create_time >= '2026-10-01' AND create_time < '2026-10-02'。- 手机号字段是字符串类型，查询时却传数字，会发生隐式转换导致索引失效，这个问题在日志里很难看出来。
追问技巧：建完索引后，把新的 EXPLAIN 结果贴回去，问「这个执行计划是否已经是最优，还有没有回表或排序」。
示例输出
示例，仅供参考（节选）
| 排名 | SQL 摘要 | 执行次数 / 天 | 平均耗时 | 主要原因 |
|---|---|---|---|---|
| 1 | 按用户查最近订单 | 120 万 | 180 ms | 只有 user_id 单列索引，排序产生文件排序 |
| 2 | 按日期统计订单 | 2 万 | 1.2 s | 对 create_time 使用了 DATE() 函数，索引失效 |
sql
-- 覆盖排名 1 的查询：等值条件 user_id 在前，排序字段 create_time 在后
ALTER TABLE orders ADD INDEX idx_user_ctime (user_id, create_time);
-- 原有的 idx_user_id (user_id) 被新索引的最左前缀覆盖，确认无其他依赖后可删除改写排名 2：
sql
SELECT COUNT(*) FROM orders
WHERE create_time >= '2026-10-01' AND create_time < '2026-10-02';同款作品
用这条提示词做出来的作品；原作者会因此获得积分
还没有同款，来做第一个。
0 条评论
还没有评论，来抢沙发～