Using index 表示使用覆盖索引，即查询所需所有列（SELECT 和 WHERE 涉及字段）均被同一索引最左前缀完全覆盖，无需回表；而 Using where; Using index 表明虽覆盖索引，但部分 WHERE 条件无法下推至存储引擎层过滤，需 server 层二次筛选，导致扫描行数增多、filtered 偏低。
Extra 列里出现 Using index 是好事，但不等于没索引问题——它只说明用了覆盖索引，不代表查询设计合理、索引结构最优，更不掩盖 Using where; Using index 或 Using index condition 场景下可能存在的冗余字段或顺序缺陷。
怎么一眼看出 Using index 是真覆盖还是假高效
覆盖索引的本质是：查询中 SELECT 的所有列 + WHERE 用到的所有列，全部落在同一个索引的最左前缀范围内。
常见误判点：
- 有
Using index，但WHERE条件用了函数（如WHERE YEAR(hire_time) = 2023）→ 实际走不了索引范围扫描，type可能是index或ALL，性能仍差 - 索引是
(name, age, position)，但查询写成SELECT * FROM employees WHERE age = 25→ 不满足最左前缀，Extra不会显示Using index，哪怕age在索引里 -
SELECT中包含TEXT或BLOB字段 → 即使其他字段被索引覆盖，InnoDB 也无法把大字段存进二级索引页，Using index不会出现
Using index 和 Using where; Using index 的关键区别在哪
两者都表示走了覆盖索引，但过滤动作发生的层级不同，直接影响扫描行数和响应稳定性：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
-
Using index：整个WHERE条件都能用索引精确匹配或范围扫描（比如WHERE name = 'Alice' AND age BETWEEN 20 AND 30），引擎层直接筛完，不回表也不在 server 层再过滤 -
Using where; Using index：索引覆盖了所有字段，但WHERE中有无法下推到引擎层的条件，例如LIKE '%suffix'、IS NULL、或者涉及隐式类型转换（如字符串字段查WHERE status = 1）→ 这些条件必须由 server 层对引擎返回的每一行再做一次判断 - 实际影响：
Using where; Using index的rows值往往偏高，因为引擎返回了更多中间结果；而filtered列如果远低于 100，就是 server 层过滤掉大量数据的信号
为什么有时加了索引却看不到 Using index
不是索引没生效，而是“覆盖”这个前提没达成。几个高频漏点：
-
SELECT *：除非是聚簇索引（主键索引）本身，否则二级索引不可能覆盖所有列，Extra一定不会是Using index - 查询中用了
DISTINCT、GROUP BY、ORDER BY非索引字段 → 即使SELECT字段全在索引里，也可能触发Using temporary或Using filesort，挤掉Using index - 索引字段含
NULL且查询条件为IS NOT NULL：InnoDB 对NULL的处理会让部分优化失效，Extra可能退化为Using where - MySQL 版本低于 5.6：不支持
Index Condition Pushdown，某些本该下推的条件被迫留在 server 层，导致Using where; Using index出现频率更高，甚至误判为“没走索引”
真正要盯的不是有没有 Using index，而是它出现时对应的 key_len 是否合理、rows 是否随数据增长线性上升、以及 filtered 是否稳定在 80 以上。这些比单看 Extra 更早暴露索引设计隐患。
