读放大主要发生在二级索引查询需回表时，因二级索引仅存索引列和主键，查非覆盖列须二次访问聚簇索引，引发多次随机I/O、缓存失效及MVCC版本检查；可通过覆盖索引、紧凑主键等优化避免。
SQL数据库中的读放大，主要发生在使用二级索引（非聚簇索引）进行查询时，因需要回表（Bookmark Lookup / Row Lookup）而引发的额外I/O和CPU开销。本质是：用索引快速定位记录位置后，还得再根据主键或物理地址去主键索引（聚簇索引）中捞出完整行数据——这一“二次访问”就是读放大的核心来源。
二级索引只存储索引列 + 主键值（MySQL InnoDB），不包含其他字段。当查
询语句涉及的列不在该二级索引中（即非覆盖索引），数据库就必须拿着查到的主键，回到聚簇索引里再次查找整行数据。
SELECT name, email FROM users WHERE city = 'Beijing'，若只有(city)二级索引，但name和email不在索引中，就会回表一次逻辑查询可能演变成多次物理读取：先扫二级索引B+树（可能多层）、再对每个匹配主键逐个访问聚簇索引叶节点（又是多层B+树查找）。这不仅增加I/O次数，还破坏顺序性、降低缓存命中率。
核心思路是让查询在二级索引内完成，即构建覆盖索引（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），会导致二级索引中存储的主键值变大，不仅占用更多空间，还会让二级索引更“胖”，间接加剧缓存压力和扫描开销。