17370845950

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 = ? AN

  

  D 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 更治本。