EXPLAIN中type=ALL表示全表扫描，应立即警觉；主因是缺失索引、对索引列用函数、隐式类型转换或违反最左前缀原则；联合索引顺序需按区分度、WHERE、ORDER BY/GROUP BY优化；覆盖索引可避免回表；冗余、低区分度或零使用索引应及时删除。
为什么 EXPLAIN 看到 type=ALL 就该警觉
这表示 MySQL 正在全表扫描，哪怕只有几千行，一旦加了 WHERE 条件却没走索引，查询延迟就可能从毫秒级跳到秒级。根本原因常是字段没建索引、用了函数或隐式类型转换。
-
WHERE created_at > DATE_SUB(NOW(), INTERVAL 7 DAY)—— 对索引列用函数，created_at索引失效 -
WHERE user_id = '123'而user_id是INT类型 —— 字符串和数字比较触发隐式转换，索引失效 - 联合索引
(a, b, c)，但查询只用WHERE b = ?—— 不满足最左前缀，无法命中
联合索引的字段顺序不是随便排的
顺序决定哪些查询能走索引、哪些不能。核心原则：把区分度高、且经常出现在 WHERE 中的字段放前面；排序（ORDER BY）和分组（GROUP BY）字段尽量接在后面，避免额外排序开销。
- 高频查询是
WHERE status = ? AND created_at > ? ORDER BY updated_at DESC→ 建索引(status, created_at, updated_at) - 如果把
updated_at放第一位，WHERE status = ?就只能走索引的最左前缀，但无法利用后两列做范围过滤+排序 -
SELECT * FROM t WHERE a = 1 AND b > 10 ORDER BY c—— 索引(a, b, c)可覆盖过滤和排序；换成(a, c, b)，b > 10后c的有序性就断了
SELECT * 和覆盖索引之间的性能鸿沟
当查询能被索引字段完全满足（即“覆盖索引”），MySQL 就不必回表查聚簇索引，I/O 直接少一次。但前提是 SELECT 列必须全部包含在索引定义中，且顺序无关。
- 表有索引
(user_id, order_time, amount)，执行SELECT user_id, amount FROM orders WHERE user_id = 123→ 覆盖索引，快 - 同样索引，执行
SELECT user_id, amount, remark FROM orders WHERE user_id = 123→remark不在索引里，必须回表，慢 - 注意：
WHERE条件中的字段也得算进“覆盖”范围；比如WHERE user_id = ? AND amount > ?，那索引至少得含user_id, amount才可能覆盖
什么时候该删索引而不是加索引
索引不是越多越好。每多一个索引，写操作（INSERT/UPDATE/DELETE）就要多维护一份 B+ 树，还吃内存和磁盘空间。真正该删的是那些长期没被用到、或被其他索引完全覆盖的索引。
- 查
information_schema.STATISTICS或用sys.schema_unused_indexes（MySQL 8.0+）识别零使用索引 - 存在索引
(a)和(a, b)，那么(a)几乎总是冗余的 —— 单列查询可用(a,b)，联合查询更需要它 - 低区分度字段（如
gender只有 ‘M’/‘F’）单独建索引意义极小，除非配合其他字段构成联合索引的前导列
SELECT index_name, seq_in_index, column_name FROM information_schema.STATISTICS WHERE table_schema = 'your_db' AND table_name = 'orders' ORDER BY index_name, seq_in_index;
索引优化不是一锤子买卖，关键在于结合慢查询日志 + EXPLAIN + 实际数据分布反复验证。最容易被忽略的，是业务逻辑变更后旧索引是否还匹配新查询模式——比如新增一个按时间范围+状态组合筛选的报表接口，但现有索引只覆盖单字段，这时候补联合索引比调优 SQL 更治本。
