EXPLAIN显示Using index代表没回表，因为该提示表明查询所需所有字段均包含在二级索引中，MySQL可直接从索引叶子节点获取全部数据，无需再根据主键回聚簇索引查找整行。
回表无法完全消除，但可以大幅减少甚至规避——关键不是“能不能避免”，而是“哪些字段必须查、哪些其实能不查”。
为什么EXPLAIN显示Using index就代表没回表？
因为Using index表示查询所需的所有列，都已包含在当前使用的二级索引中，MySQL直接从索引叶子节点取值，无需再拿主键去聚簇索引捞整行数据。
- 二级索引的叶子节点天然带主键（哪怕你没显式声明），所以
SELECT id, name FROM user WHERE name = 'Alice'只要name有索引，就满足覆盖条件 - 但如果加了
age，而索引只有(name)，就会触发回表；此时要改成联合索引(name, age) -
SELECT *几乎必然回表，除非表只有主键+被索引列（极少见）
联合索引怎么设计才真正压住回表？
不是堆字段越多越好，得按「查询条件 + 查询返回字段」一起规划。联合索引(a, b, c)能覆盖的查询，必须满足：WHERE条件能用上最左前缀，且SELECT字段全在a,b,c里（或主键id，它自动附带）。
- 常见错误：建了
(name, age)，却查SELECT name, city FROM ... WHERE age = 25→age不是最左列，索引失效，更别说覆盖 - 正确做法：如果常查
city和age，WHERE又常用city，那就建(city, age)；若还常查name，再扩展为(city, age, name) - 注意顺序：把过滤性高（区分度大）、WHERE中必用的列放最左；返回字段放右边，不影响索引匹配，但影响覆盖能力
回表开销到底有多大？别只看执行计划
EXPLAIN里没Using index只是预警，真实代价要看命中行数和数据分布。100行回表可能毫秒级，10万行就可能拖垮QPS。
- 回表本质是随机IO：二级索引查到的主键通常是无序的（比如
id IN (1001, 289, 5003...)），导致聚簇索引访问跳着读页，缓冲池命中率骤降 - Buffer Pool压力隐性：频繁回表会把热数据页挤出内存，连带拖慢其他查询
- 验证方法：用
SHOW STATUS LIKE 'Innodb_buffer_pool_read%'对比优化前后物理读次数；或开慢日志看单条SQL的rows_examined是否远大于rows_sent
最容易被忽略的是业务层冗余字段——比如前端明明只展示用户名和头像URL，后端却SELECT *再在代码里挑字段。这种地方加个覆盖索引，比调优SQL语句见效快得多。
