“Using index”表示纯索引覆盖，所有查询字段和条件均被索引包含，彻底避免回表及随机I/O；而“Using where; Using index”说明仍有部分字段或条件未被覆盖，需回表，性能显著下降。
因为索引覆盖直接消除了回表所需的随机 I/O，而随机 I/O 是数据库性能的最大瓶颈之一。
为什么“Using index”比“Using where; Using index”快得多
前者表示查询所有字段（SELECT、WHERE、ORDER BY、GROUP BY 涉及的列）都严格落在索引中；后者说明虽然走了索引，但仍有部分条件或字段需回表取数据。例如：SELECT name FROM users WHERE age = 25 AND city = 'Beijing'，若索引是 (age, name)，则 city 不在索引里，优化器无法跳过回表——Extra 就会是 Using where; Using index，不是真正覆盖。
- 只有
Using index才代表纯索引扫描，无任何聚簇索引访问 -
Using index condition是索引条件下推（ICP），仍可能触发回表，不等于覆盖 - 哪怕只多一个未被索引覆盖的
ORDER BY字段，也可能导致全表排序或临时表，彻底失效
联合索引字段顺序怎么排才真正生效
顺序必须同时满足最左前缀 + 查询覆盖需求。比如高频查询是 SELECT user_id, status FROM orders WHERE shop_id = ? AND created_at > ? ORDER BY created_at DESC，那就不能只建 (shop_id, user_id, status) —— 因为 created_at 既用于过滤又用于排序，必须前置或紧随过滤列之后。
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- WHERE 等值条件列优先靠左（如
shop_id） - 范围条件列（
created_at > ?）必须放在等值列之后，且不能再有其他等值列跟在其后 - SELECT 和 ORDER BY 字段补在右侧，确保整条查询路径被“罩住”
- 主键（如
id）通常不用显式加入，因为 InnoDB 二级索引叶子节点自带主键值
EXPLAIN 看到 type=ref 但没 Using index，问题出在哪
常见原因不是索引没建对，而是查询本身破坏了覆盖前提。比如：
- 用了函数：
WHERE UPPER(name) = 'JOHN'→ 索引失效，更别说覆盖 - 隐式类型转换：
WHERE user_id = '123'（user_id是 INT）→ 索引可用但无法覆盖 - SELECT *：哪怕索引包含全部字段，
*也会让优化器放弃覆盖（尤其当表含 TEXT/BLOB 时） - OR 条件：
WHERE a = 1 OR b = 2很难走单个覆盖索引，常退化为全表扫描
真正难的不是建索引，而是让每一条上线的 SQL 都“严丝合缝”地对齐索引结构——字段顺序、是否加函数、有没有多余列，差一点，就从 20ms 掉回 2s。
