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