MySQL查询的速率限制瓶颈：索引查询还是磁盘读取？

针对select * from table where c1=v1 and c2=v2 and c3=v3这类基础MySQL查询，我发现查询延迟和返回数据量正相关——返回500行比200行更慢，这点我能理解，但想搞清楚：到底是索引查询阶段还是磁盘读取阶段导致了这种差异？

我对MySQL查询的底层逻辑理解是：先通过索引找到磁盘上的数据偏移位置，再根据位置读取实际数据（如果我的理解有误，请帮忙纠正）。

那是不是可以这么判断：如果索引设计合理，速率瓶颈就是磁盘读取？如果索引设计差，索引搜索阶段会变成线性扫描，进而拖慢整个查询？

先修正你的查询流程理解 #

你的核心逻辑没问题，但补充两个关键细节：

• 若使用的是二级索引，InnoDB会先通过索引定位到符合条件的主键值，再通过主键索引（聚簇索引）回表读取完整行数据；
• 若使用的是覆盖索引（索引包含查询所需的所有字段），则直接从索引返回结果，无需再读取磁盘上的行数据。

为什么返回行数越多延迟越高？ #

本质是需要处理、读取、传输的数据量更大，分两种场景具体分析：

1. 索引设计良好的场景
   • 索引查询阶段耗时稳定：B+树索引可以快速定位所有符合条件的行位置，这个阶段的耗时几乎不随返回行数增加而明显变化。
   • 瓶颈在磁盘读取+数据传输：返回500行意味着要从磁盘读取500条完整记录（因为你用了SELECT *，必然触发回表），磁盘IO的数据量远大于200行；同时将这些数据从服务端传输到客户端也需要更多时间，这两部分是延迟增加的主要原因。
2. 索引设计不佳的场景
   • 索引查询阶段本身就是瓶颈：如果没有合适的索引，MySQL会执行全表扫描（线性遍历所有行），返回行数越多，需要扫描的总行数也越多（要筛选出符合条件的数据），此时索引扫描和磁盘读取都会拖慢查询，延迟上升的幅度会比索引良好的场景更明显。

额外建议 #

避免用SELECT *，只查询需要的字段，这样有可能用到覆盖索引，跳过回表的磁盘读取步骤，即使返回大量数据，延迟也会大幅降低。

内容的提问来源于stack exchange，提问作者LookIntoEast