WHERE字段无索引将导致全表扫描，查询变慢十倍；用EXPLaiN检查type为ALL即未走索引；应建单列索引并避免在索引字段上使用函数。
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 内存。真正要紧的是搞清每个查询的真实执行路径，而不是靠“先加上再说”。