EXPLAIN 显示 type=ALL 表示 MySQL 正在执行全表扫描，逐行读取整张表匹配条件，数据量过万时响应明显变慢；常见原因包括 WHERE 字段无索引、使用函数或隐式类型转换。
为什么 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 并不能阻止这个过程。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
实操建议：
- 让
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 查询，索引就悄悄失效了。
