MySQL以16KB页为单位从磁盘加载数据到InnoDB缓冲池,未命中则同步读整页;WHERE条件优先在存储引擎层用索引过滤,无法下推的表达式由Server层二次过滤;SELECT列指定可避免读溢出页,LIMIT仅在能索引定位时加速。

MySQL 执行 SELECT 时,数据从磁盘到内存的路径是怎样的
MySQL 不会直接“按行”从磁盘读取数据;它以 page(页)为单位加载数据,InnoDB 默认页大小是 16KB。一次查询哪怕只查 1 行,只要该行不在缓冲池中,就得把整页(含可能几十行)从磁盘读入 innodb_buffer_pool。
- 先查
buffer_pool:命中则直接返回,不碰磁盘 - 未命中则触发同步 I/O:定位数据页 → 读取整页 → 解析页内记录 → 过滤出满足 WHERE 条件的行
- 如果用了二级索引,还需回表:先查索引页,再根据主键值去聚簇索引页找完整行(又是一次或多次页加载)
- 全表扫描时,并非逐行读,而是按区(
extent,64 个连续页)预读,但实际仍以页为单位载入和遍历
WHERE 条件是在哪一层过滤的:存储引擎层还是 Server 层
过滤发生在两层协同完成,但关键判断在存储引擎层:
-
WHERE中能被索引覆盖的条件(如id = 5、status IN (1,2)),由InnoDB在读取页后、构造记录前就完成快速跳过(使用索引 B+ 树导航 + 页内二分/游标遍历) - 无法下推到引擎的表达式(如
UPPER(name) = 'ABC'、涉及函数或跨列计算),会在 Server 层对引擎返回的每行做二次计算过滤 - 注意:即使
EXPLAIN显示type=ref,若Extra列出现Using where,说明仍有 Server 层过滤——这意味引擎返回了多余行,增加了网络和 CPU 开销
SELECT * 和 SELECT col1, col2 在数据读取上有区别吗
有本质区别,尤其当表包含大字段(TEXT、BLOB)或行长度较大时:
本书全面介绍PHP脚本语言和MySOL数据库这两种目前最流行的开源软件,主要包括PHP和MySQL基本概念、PHP扩展与应用库、日期和时间功能、PHP数据对象扩展、PHP的mysqli扩展、MySQL 5的存储例程、解发器和视图等。本书帮助读者学习PHP编程语言和MySQL数据库服务器的最佳实践,了解如何创建数据库驱动的动态Web应用程序。
-
SELECT *:InnoDB 必须读取整行物理记录(包括溢出页中的大字段),即使你最终不使用它们 -
SELECT col1, col2(且这两列都在主键页内):InnoDB 可启用read view+record read优化,只读取所需列对应的数据,跳过溢出页(前提是没用到SELECT *或隐式需要全部列的场景,如触发TRIGGER) - 但注意:如果查询走了二级索引覆盖(
Using index),那无论写*还是具体列,都只读索引页,不回表——此时列数不影响 I/O,只影响网络传输量
为什么加 LIMIT 1 有时并不能加速慢查询
因为 LIMIT 是结果截断,不是执行剪枝:
- 如果没走索引,MySQL 仍需扫描全表(或全索引)直到找到第 1 条匹配行——最坏情况仍是 O(n)
- 如果
ORDER BY配合LIMIT(如ORDER BY created_at DESC LIMIT 1),而created_at没索引,就要排序全部数据再取头,LIMIT完全无效 - 真正起效的前提是:能用索引直接定位到“第一个”满足条件的记录位置(例如
WHERE status=1 ORDER BY id ASC LIMIT 1,且(status, id)有联合索引) - 验证方式:看
EXPLAIN的rows值是否显著下降;若仍是全表行数,LIMIT就没省 I/O
EXPLAIN SELECT * FROM orders WHERE user_id = 123 ORDER BY created_at DESC LIMIT 1;
真正影响读取效率的,从来不是 SQL 写法表面的简洁,而是数据如何组织、索引如何设计、以及每一行背后的页加载与过滤时机。很多“慢查询”优化,本质是把 “让 MySQL 少读几个页” 变成可落地的动作,而不是调参数或改写 SQL 本身。









