为什么 EXPLAIN
显示 type=ALL
就该警惕
这代表 MySQL 正在执行全表扫描——它会逐行读取整张表来匹配条件，数据量一过万行，响应就明显变慢。常见诱因是
WHERE字段没索引、用了函数或隐式类型转换，比如
WHERE YEAR(create_time) = 2024或
WHERE user_id = '123'（字段是
INT但传了字符串）。
实操建议：
用EXPLAIN SELECT ...看
key列是否为
NULL，
rows是否接近表总行数 检查
WHERE中所有字段是否都落在已有索引的最左前缀上（复合索引
(a,b,c)支持
a、
a,b、
a,b,c，但不支持单独
b或
b,c） 避免在索引列上使用函数、运算符（如
UPPER(name)、
age + 1 > 18），改写为可走索引的形式
复合索引怎么建才不浪费
不是字段越多越好，顺序和选择直接影响能否命中。MySQL 只能高效利用索引的“连续最左前缀”，且范围查询（
>、
BETWEEN、
LIKE 'abc%'）之后的字段无法再用于索引查找。
实操建议：
把等值查询字段放前面（如WHERE status = 1 AND category_id = 5→ 索引优先建
(status, category_id)） 范围查询字段放最后（如需加时间范围
AND created_at > '2024-01-01'，则建为
(status, category_id, created_at)） 避免冗余索引：已有
(a,b)再建
(a)是多余的；但
(a,b)和
(b,a)不等价，按实际查询模式选
ORDER BY
和 LIMIT
为什么也会触发全表扫描
即使
WHERE条件走了索引，如果
ORDER BY字段不在同一索引中，MySQL 可能先查出所有匹配行再排序，导致临时表 + 文件排序（
Extra显示
Using filesort）。而
LIMIT 10并不能阻止这个过程。
实操建议：
让ORDER BY字段尽可能包含在
WHERE使用的索引末尾，例如
WHERE a = ? ORDER BY b→ 建索引
(a, b)若只查少量字段，考虑覆盖索引：把
SELECT中所有字段都加入索引（如
SELECT id, name FROM t WHERE status=1 ORDER BY create_time→
(status, create_time, id, name)），避免回表 慎用
SELECT *，它会让覆盖索引失效，强制回表读取整行
哪些操作会让已有索引彻底失效
索引不是建了就永远有效。某些看似无害的写法，会让优化器主动放弃索引，退化为全表扫描。
实操建议：
避免OR连接不同字段（如
WHERE a = 1 OR b = 2），除非两个字段都有独立索引且满足一定条件；改用
UNION拆分 不要用
!=或 做主键/索引字段判断，它通常无法使用索引范围扫描
LIKE以通配符开头（
LIKE '%abc'）必然无法使用索引；若必须模糊查前缀，确保是
LIKE 'abc%'确认字符集和排序规则一致：关联字段或
WHERE字段若跨表存在
utf8mb4_general_ci和
utf8mb4_unicode_ci混用，可能导致索引失效 索引优化不是一劳永逸的事，每次新增查询逻辑、修改字段类型或升级 MySQL 版本后，都要重新验证
EXPLAIN结果。真正容易被忽略的是业务语义变化带来的隐式转换——比如原本手机号存为
VARCHAR，某天开始用
INT查询，索引就悄悄失效了。
