慢查询优化应先看执行计划而非盲目加索引；需检查是否走索引、扫描行数、临时表及文件排序；索引失效常见于函数操作、隐式转换、最左前缀不满足、LIKE前导通配符等；ORDER BY/GROUP BY易引发性能问题，应建合适联合索引；慢查询日志中Rows_examined与Rows_sent比值反映逻辑效率；配置long_query_time=0.1、log_queries_not_using_indexes=ON可提前发现隐患；底层状态如数据分布、锁等待、Buffer Pool命中率更关键。
慢查询不一定是索引缺失，先看执行计划
很多同学一看到 SELECT 慢就立刻加索引，结果发现没用甚至更慢。真正该做的第一步是用 EXPLAIN 看执行计划，确认是否真的走了索引、扫描行数是否合理、有没有临时表或文件排序。
常见误导现象：
-
type是ALL或index→ 全表/全索引扫描，大概率缺索引或索引失效 -
rows远大于实际返回行数 → 优化器预估偏差大，可能因统计信息过期（可运行ANALYZE TABLE） -
Extra出现Using filesort或Using temporary→ 排序或分组没走索引，不是“查得慢”，而是“算得慢”
索引失效的典型场景比你想象中多
即使建了索引，WHERE 条件写法不对，MySQL 一样不走。关键不是“有没有索引”，而是“能不能用上”。
高频踩坑点：
- 对索引字段做函数操作：比如
WHERE YEAR(create_time) = 2024→ 改成WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31' - 隐式类型转换：
user_id是INT，但传了字符串'123'→ MySQL 自动转类型，索引失效 - 最左前缀没满足：联合索引
(a, b, c)，只查WHERE b = 1或WHERE a = 1 AND c = 1（跳过b）→ 不走索引 -
LIKE以通配符开头：WHERE name LIKE '%abc'→ 无法使用索引，LIKE 'abc%'才可以
ORDER BY 和 GROUP BY 很容易成为性能黑洞
这两个操作本身不读数据，但会触发排序和临时表，尤其在没有合适索引时，性能断崖式下跌。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 如果
ORDER BY a, b，且查询条件含WHERE a = ?，优先建联合索引(a, b)；若还带LIMIT，这个索引能避免排序 -
GROUP BY同理，但注意：MySQL 8.0+ 支持松散索引扫描（Loose Index Scan），而 5.7 只支持紧凑索引扫描（Tight Index Scan），对索引结构更敏感 - 避免在
SELECT中用非索引字段做GROUP BY，比如GROUP BY SUBSTRING(email, 1, 5)→ 必走临时表
慢查询日志里藏着比索引更关键的信息
开启 slow_query_log 后，别只盯着 Query_time，重点看 Rows_examined 和 Rows_sent 的比值。如果前者是后者的几百倍，说明“查得多、返回少”，大概率是逻辑设计问题（比如用子查询代替 JOIN，或在应用层循环查）。
几个易被忽略的配置项：
-
long_query_time = 0.1（而非默认 1 秒）→ 小延迟积少成多，早暴露问题 -
log_queries_not_using_indexes = ON→ 即使不慢，也记录没走索引的查询，防患于未然 -
min_examined_row_limit = 1000→ 过滤掉那些只扫几行的“伪慢查询”，聚焦真瓶颈
复杂点往往不在 SQL 写法，而在数据分布偏斜、锁等待、Buffer Pool 命中率低这些底层状态——查 SHOW ENGINE INNODB STATUS 和 information_schema.INNODB_METRICS 比死盯索引更有价值。
