避免全表扫描的关键是让查询有效利用索引，需确保WHERE、JOIN、ORDER BY、GROUP BY等子句字段落在合适索引上；索引失效常见于对索引字段做函数操作等情况。
避免 MySQL 全表扫描的关键是让查询能有效利用索引，而不是逐行检查所有数据。核心思路是：让 WHERE、JOIN、ORDER BY、GROUP BY 等子句中的字段尽可能落在已有的合适索引上。
确保查询条件走索引
全表扫描最常见原因是 WHERE 条件无法使用索引。以下情况容易导致索引失效：
- 对索引字段做函数操作，如 WHERE YEAR(create_time) = 2023 → 改为 WHERE create_time >= '2023-01-01' AND create_time
- 隐式类型转换，如字段是 VARCHAR，却用数字查询：WHERE mobile = 13812345678 → 改为 WHERE mobile = '13812345678'
- 使用 LIKE '%abc' 开头的模糊匹配（前导通配符），无法用 B+ 树索引 → 若必须模糊查，可考虑全文索引或倒排索引方案
- OR 连接多个条件时，部分字段无索引 → 尽量改写为 UNION 或确保每个 OR 分支字段都有索引
合理设计复合索引（最左前缀原则）
单列索引效率有限，多条件查询应建联合索引。例如查询常带 WHERE status = ? AND category = ? ORDER BY created_at DESC，推荐建索引：
INDEX idx_status_cate_time (status, category, created_at)
注意顺序：等值条件（=）放前面，范围条件（>、
避免 SELECT * 和不必要的排序/分组
全表扫描有时不是因为没索引，而是优化器判断“用索引回表成本高于直接扫表”。常见诱因：
- SELECT * 导致大量回表读取行数据 → 只查必需字段，必要时用覆盖索引（索引包含 SELECT 所有字段）
- ORDER BY 非索引字段 或 GROUP BY 字段未索引 → 强制触发 filesort 或 temporary 表，可能让优化器放弃索引
- 表数据量小（如几千行），MySQL 可能认为全表扫描比走索引更快 → 此时无需强求，但需确认是否未来会增长
定期分析执行计划与索引使用情况
用 EXPLAIN 查看实际执行路径，重点关注：
- type：尽量为 ref、range、const；避免 ALL（全表扫描）和 index（全索引扫描）
- key：显示实际使用的索引名，为空说明没走索引
- rows：预估扫描行数，过大说明索引选择不佳或缺失
- Extra：出现 Using filesort 或 Using temporary 是性能隐患信号
