type=all表示mysql执行全表扫描，即未使用索引、逐行读取整张表；常见原因包括无索引、索引顺序错配、函数包裹字段、隐式类型转换及统计信息过期。

点“解释”按钮后看到 type=ALL 就是全表扫描

Navicat 里判断是否发生全表扫描，最直接的依据就是执行计划中 type 列的值为 ALL。这不是警告，而是明确结论：数据库没走索引，正一行行读完整张表。

常见诱因包括：

• WHERE 条件字段没建索引，或索引字段顺序与查询条件不匹配（比如索引是 (a,b)，但只查 b = ?）
• 对索引字段用了函数或表达式，如 YEAR(create_time) = 2023、UPPER(name) = 'ABC'
• 隐式类型转换，比如字段是 VARCHAR，但传入数字参数：user_id = 123（而 user_id 实际是字符串类型）
• 使用了 OR 连接多个非索引字段，或 !=、NOT IN 等难以利用索引的操作

possible_keys 有值但 key 为空，说明索引被“看见”却没被选中

这比完全没索引更值得细看——优化器明明知道有可用索引（possible_keys 显示了候选索引），却放弃使用（key 为空），往往是因为统计信息过期、索引选择性差，或查询条件导致优化器误判成本更低。

实操建议：

• 先运行 ANALYZE TABLE table_name 更新统计信息（MySQL），让优化器重新评估
• 检查该索引是否覆盖了查询中所有 WHERE 和 ORDER BY 字段；若 ORDER BY 字段不在索引中，可能触发 Using filesort，进而让优化器放弃索引
• 用 EXPLAIN FORMAT=JSON 查看详细成本估算（Navicat Premium 支持），重点关注 cost_info 中的 query_cost 和各访问路径对比

对比 rows 和实际结果集大小，确认扫描是否失控

rows 是 MySQL 预估要扫描的行数，不是返回行数。如果 rows 是 50 万，但最终只返回 10 行，基本可断定存在严重冗余扫描——要么索引失效，要么条件过滤能力极弱。

navicatmysql

Navicat For MySQL

下载

注意两个易忽略点：

• rows 值来自采样估算，不一定准；若表刚大批量写入或长期未 ANALYZE，该值可能严重偏离真实情况
• 多表 JOIN 时，rows 是单表预估，叠加后实际 I/O 可能呈指数增长；此时更要盯紧驱动表的 type 和 rows
• Navicat 的“解释”默认发的是 EXPLAIN，不是 EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=TREE（MySQL 8.0.16+），它不反映真实执行耗时或实际扫描行数

别只盯着 type，Extra 里的 Using temporary 和 Using filesort 往往是全表扫描的伴生问题

这两个标记本身不等于全表扫描，但它们和 type=ALL 同时出现时，说明查询不仅扫得广，还干了额外重活：排序或分组被迫落盘，进一步放大性能损耗。

典型场景：

• ORDER BY 字段未包含在索引中，或索引顺序与 ORDER BY 不一致（如索引是 (a, b)，却 ORDER BY b, a）
• GROUP BY 没命中索引，且数据量大到无法在内存完成聚合
• DISTINCT 或 UNION 触发去重逻辑，又无合适索引支撑

真正难调的 case，往往不是单个 ALL，而是 type=ALL + Extra=Using temporary; Using filesort 的组合——这时光加索引不够，得重写逻辑或拆分查询。