EXPLAIN是诊断慢查询的首要工具：type为ALL、key为NULL、rows远超返回行数，表明索引未生效；函数操作或隐式类型转换（如VARCHAR字段传数字）破坏B+树有序性，导致全表扫描；联合索引必须满足最左前缀原则，跳过首列则整个索引失效。
EXPLAIN 是你打开慢查询真相的第一把钥匙。不看执行计划就改 SQL，等于蒙眼调索引——可能越调越慢。只要 type 出现 ALL，基本可以断定这条查询没走索引；key 为 NULL 就是索引压根没被选中；rows 值远大于实际返回行数（比如扫 50 万行只取 10 行），说明过滤效率极差。优先盯住这三个字段，比反复重写 WHERE 条件更有效。
为什么 WHERE 里用函数会让索引失效
数据库只能对索引列的原始值做快速定位，一旦你在列上套函数，比如 YEAR(create_time) = 2024 或 UPPER(name) = 'ALICE'，引擎就得先把整列数据算一遍函数结果再比对，索引彻底作废。隐式类型转换也一样：phone = 13800138000（phone 是 VARCHAR）会触发全表转换，改成 phone = '13800138000' 就立刻走索引。本质不是语法错，而是执行路径被强制绕开了 B+ 树查找。
联合索引怎么建才不白建
最左前缀不是玄学，是 B+ 树结构决定的硬约束。比如有联合索引 idx_user_status_created(user_id, status, created_at)，下面这些能用上：
WHERE user_id = 100WHERE user_id = 100 AND status = 'paid'WHERE user_id = 100 AND status = 'paid' AND created_at > '2024-01-01'
但 WHERE status = 'paid' 或 WHERE status = 'paid' AND created_at > '2024-01-01' 就完全用不上——因为树的分支是从 user_id 开始分的，跳过它就找不到入口。如果业务真有这类高频查询，别硬凑，单独建 idx_status_created(status, created_at) 更实在。
分页查到第 10000 页为什么会卡死
LIMIT 10000, 10 不是只取 10 行，而是让数据库先扫出前 10010 行，再丢掉前 10000 行。数据量越大，浪费越严重。换成游标分页：WHERE id > 10000 ORDER BY id LIMIT 10，靠主键索引直接跳转，性能差异可达数量级。注意这个方案要求排序字段必须有唯一、递增/递减索引，且不能有 NULL 值干扰顺序。
WHERE 条件是否无意中破坏了索引可用性、以及分页逻辑是否在底层做了大量无用扫描——这些细节不抠清楚，建再多索引也没用。 
