SQL查询回表次数需通过执行计划推断：使用二级索引查非索引列时，每匹配一行就回表一次，rows值近似回表次数；覆盖索引（Extra显示Using index）则回表次数为0。
SQL查询的回表次数，不能直接从执行计划里看到一个叫“回表次数”的数字，而是要通过分析执行计划中的访问路径、索引类型和输出列来推断。核心判断依据是：当使用二级索引（非聚簇索引）查数据，但查询语句需要返回非索引列时，MySQL/Oracle等数据库会根据索引中存储的主键值，再回到主键索引（聚簇索引）查找完整行记录——这个过程就叫“回表”，每次这样的跳转算一次回表。
看Extra列是否出现"Using index condition"或"Using where; Using index"
在MySQL的EXPLAIN结果中：
- "Using index"：说明走了覆盖索引，所有需要的列都在该索引里，不回表；
- "Using index condition"：用了ICP（索引下推），虽然用到了索引过滤，但如果SELECT的字段不在索引中，仍需回表；
- 没出现"Using index"，且type是"ref"/"range"/"index"等，但key显示用了某个二级索引，而SELECT包含该索引未包含的列 → 大概率每匹配一行就回表一次。
看Key列和Select Type配合判断回表触发条件
例如执行：SELECT id, name, email FROM users WHERE status=1;
- 如果
status上有普通索引，但name和email不在该索引中，那么每扫描一个满足status=1的索引项，就要拿着id（或主键）回到聚簇索引取完整行 → 回表次数 ≈ 索引扫描的行数（rows列）； - 如果把索引改成
(status, name, email)，变成覆盖索引，Extra就会显示"Using index"，回表次数降为0。
看Rows列和实际扫描行数的关系
执行计划里的rows表示优化器预估的**通过索引筛选后需要访问的记录数**。在二级索引+非覆盖场景下，这个数值通常就是回表次数的近似值：
- rows=1000，大概率要回表1000次；
- 如果查询带LIMIT 10，且优化器能利用索引快速定位前几条，rows可能很小，回表次数也就少；
- 注意：rows是预估值，不一定等于真实回表次数，但方向一致，可作为主要参考。
Oracle中对应看A-Rows与Buffers差异
在Oracle的执行计划（如DBMS_XPLAN.DISPLAY_CURSOR）中：
- A-Rows是该步骤实际返回的行数；
- Buffers是逻辑读块数；
- 如果某步是INDEX RANGE SCAN，A-Rows=500，但Buffers高达2000，说明很可能发生了大量回表（每次回表至少多读1个聚簇索引块）；
- 对比INDEX RANGE SCAN和后续TABLE ACCESS BY INDEX ROWID两步的A-Rows是否接近，若接近，基本可确认发生了逐行回表。
