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）或行长度较大时：
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 本身。
