为什么 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 更治本。
