读放大主要发生在二级索引查询需回表时，因二级索引仅存索引列和主键，查非覆盖列须二次访问聚簇索引，引发多次随机I/O、缓存失效及MVCC版本检查；可通过覆盖索引、紧凑主键等优化避免。
SQL数据库中的读放大，主要发生在使用二级索引（非聚簇索引）进行查询时，因需要回表（Bookmark Lookup / Row Lookup）而引发的额外I/O和CPU开销。本质是：用索引快速定位记录位置后，还得再根据主键或物理地址去主键索引（聚簇索引）中捞出完整行数据——这一“二次访问”就是读放大的核心来源。
为什么二级索引会触发回表
二级索引只存储索引列 + 主键值（MySQL InnoDB），不包含其他字段。当查询语句涉及的列不在该二级索引中（即非覆盖索引），数据库就必须拿着查到的主键，回到聚簇索引里再次查找整行数据。
- 例如：
SELECT name, email FROM users WHERE city = 'Beijing'，若只有(city)二级索引，但name和email不在索引中，就会回表 - 即使只查一个额外字段，只要没被索引覆盖，就可能触发回表
- 如果查询返回1000行，就可能产生1000次随机I/O（尤其在机械盘或高并发下代价显著）
回表如何放大读取量
一次逻辑查询可能演变成多次物理读取：先扫二级索引B+树（可能多层）、再对每个匹配主键逐个访问聚簇索引叶节点（又是多层B+树查找）。这不仅增加I/O次数，还破坏顺序性、降低缓存命中率。
- 二级索引页与聚簇索引页通常物理分散，导致大量随机读
- 回表过程无法利用索引下推（ICP）优化全部条件，部分过滤被迫延后到Server层
- 在MVCC场景下，回表还需检查每行的可见性版本，进一步增加CPU负担
怎么减少或避免回表
核心思路是让查询在二级索引内完成，即构建覆盖索引（Covering Index），把SELECT、WHERE、ORDER BY、GROUP BY中涉及的列都包含进去。
- 添加包含列：
CREATE INDEX idx_city_cover ON users(city) INCLUDE (name, email)（PostgreSQL 11+ / SQL Server） - 或直接建联合索引：
CREATE INDEX idx_city_name_email ON users(city, name, email)（MySQL常用） - 注意最左前缀原则：
WHERE city = ? ORDER BY name可用，但WHERE name = ?就无法走该索引 - 避免
SELECT *，只查真正需要的字段，缩小覆盖范围，降低索引体积和维护成本
聚簇索引设计也影响回表成本
在InnoDB中，主键即聚簇索引。若主键过大（如用UUID），会导致二级索引中存储的主键值变大，不仅占用更多空间，还会让二级索引更“胖”，间接加剧缓存压力和扫描开销。
- 尽量用紧凑、递增的主键（如自增BIGINT），减少二级索引体积
- 避免在频繁被作为外键或二级索引引用的列上使用长字符串主键
- 若业务必须用逻辑主键，可考虑“主键+唯一约束”分离设计，用隐藏自增ID做聚簇索引
