WHERE 条件字段没加索引，查询直接变慢十倍
MySQL 在执行
SELECT时，如果
WHERE中的字段没有索引，就会触发全表扫描。尤其当表有百万级以上数据，哪怕只查 1 行，也要遍历所有行才能确认匹配结果。
实操建议：
用EXPLAIN SELECT ...看
type字段：出现
ALL就是全表扫描；
ref或
range才算走了索引 单列查询优先建单列索引，比如常查
user_id，就建
INDEX idx_user_id (user_id)避免在索引字段上做函数操作，例如
WHERE YEAR(create_time) = 2024会让
create_time索引失效；应改写为
WHERE create_time >= '2024-01-01' AND create_time字符串字段用
LIKE时，只有左前缀匹配能走索引：
name LIKE '张%'可以，
name LIKE '%三'或
name LIKE '%王%'不行
联合索引的字段顺序不是随便排的
MySQL 的联合索引遵循「最左前缀原则」，不是字段堆在一起就行。顺序错了，索引可能完全用不上。
比如建了联合索引
INDEX idx_status_type (status, type)：
WHERE status = 1✅ 走索引
WHERE status = 1 AND type = 2✅ 走索引
WHERE type = 2❌ 不走索引（跳过了最左字段
status）
WHERE type = 2 AND status = 1✅ 仍可走索引（MySQL 会自动调整条件顺序）
排序建议：把区分度高（值分布广）、经常单独出现在
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)，虽然能覆盖，但会显著增大索引体积，影响写入性能和内存占用。
权衡点：
只对高频、低延迟要求的SELECT场景考虑覆盖索引 避免把
TEXT、
JSON或长
VARCHAR字段加入索引 用
EXPLAIN看
Extra列：出现
Using index表示命中覆盖索引
ORDER BY 和 GROUP BY 容易忽略索引适配
即使
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 内存。真正要紧的是搞清每个查询的真实执行路径，而不是靠“先加上再说”。
