mysql查询优化中的索引选择与使用技巧_网络技术

WHERE字段无索引将导致全表扫描，查询变慢十倍；用EXPLAIN检查type为ALL即未走索引；应建单列索引并避免在索引字段上使用函数。

MySQL 在执行 SELECT 时，如果 WHERE 中的字段没有索引，就会触发全表扫描。尤其当表有百万级以上数据，哪怕只查 1 行，也要遍历所有行才能确认匹配结果。

实操建议：

用 EXPLAIN SELECT ... 看 type 字段：出现 ALL 就是全表扫描；ref 或 range 才算走了索引
单列查询优先建单列索引，比如常查 user_id，就建 INDEX idx_user_id (user_id)
避免在索引字段上做函数操作，例如 WHERE YEAR(create_time) = 2025 会让 create_time 索引失效；应改写为 WHERE create_time >= '2025-01-01' AND create_time
字符串字段用 LIKE 时，只有左前缀匹配能走索引：name LIKE '张%' 可以，name LIKE '%三' 或 name LIKE '%王%' 不行

MySQL 的联合索引遵循「最左前缀原则」，不是字段堆在一起就行。顺序错了，索引可能完全用不上。

比如建了联合索引 INDEX idx_status_type (status, type)：

排序建议：把区分度高（值分布广）、经常单独出现在 WHERE 中、或用于 ORDER BY 的字段放左边。例如用户表中 tenant_id 区分度远高于 is_deleted，联合索引应为 (tenant_id, is_deleted)，而不是反过来。

覆盖索引指查询所需的所有字段都包含在索引中，MySQL 直接从索引 B+ 树叶子节点取值，不用再回主键索引查整行数据——这叫「回表」，IO 开销大。

例如表 orders 主键是 id，有索引 INDEX idx_uid_status (user_id, status)：

SELECT user_id, status FROM orders WHERE user_id = 123 AND status = 1;

这条能走覆盖索引；但下面这句不行：

SELECT user_id, status, amount FROM orders WHERE user_id = 123 AND status = 1;

因为 amount 不在索引里，必须回表。此时若强行加进联合索引变成 (user_id, status, amount)，虽然能覆盖，但会显著增大索引体积，影响写入性能和内存占用。

权衡点：

即使 WHERE 走了索引，如果 ORDER BY 字段不在索引中或顺序不匹配，MySQL 仍要额外排序（Using filesort），性能断崖式下跌。

关键规则：

ORDER BY a, b 要走索引，索引必须是 (a, b) 或更长前缀如 (a, b, c)；(b, a) 不行
ORDER BY a DESC, b ASC 需要索引明确声明方向：INDEX idx_a_b (a DESC, b ASC)（MySQL 8.0+ 支持，5.7 不支持混合方向）
GROUP BY 原理同 ORDER BY，默认隐式排序，所以同样依赖索引顺序
如果业务允许，可加 ORDER BY NULL 显式禁用排序，避免无谓开销

一个典型陷阱：WHERE a = 1 ORDER BY b，只建 (a) 索引不够，必须建 (a, b) 才能消除 Using filesort。

索引不是越多越好，每多一个索引都会拖慢 INSERT/UPDATE/DELETE，还会吃更多磁盘和 Buffer Pool 内存。真正要紧的是搞清每个查询的真实执行路径，而不是靠“先加上再说”。