单条SQL的逻辑读、物理读页数需通过全局状态变量差值法获取：执行前取Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads初值，执行后取终值，差值即分别为逻辑读次数和物理读页数（每+1≈至少1页）。
怎么直接拿到单条SQL的逻辑读、物理读页数
MySQL不提供“执行完立刻返回本次读了多少页”的函数，EXPLAIN只给预估行数，SHOW PROFILE在 5.7+ 已弃用且不统计页级IO。真要抓单次SQL的逻辑读、物理读，只能靠前后差值法——用Innodb_buffer_pool_read_requests和Innodb_buffer_pool_reads这两个全局状态变量做减法。
实操要点：
- 必须在同一线程（即同一个连接）里完成“查初值 → 执行SQL → 查终值”，不能跨会话或用
SELECT ... INTO @var后丢掉连接 - 执行前先清空可能干扰的缓存：
FLUSH STATUS不是必须，但RESET QUERY CACHE无效（Query Cache 在 8.0 已移除），重点是避免其他线程刷脏页影响计数 - 两个变量单位都是“次数”，不是字节或毫秒；
Innodb_buffer_pool_reads每+1 ≈ 至少一次磁盘read()调用，对应至少一页（16KB） - 示例流程：
SELECT VARIABLE_VALUE INTO @init_reads FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads';<br>SELECT VARIABLE_VALUE INTO @init_requests FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests';<br><br>-- 这里执行你的目标 SQL<br>SELECT * FROM orders WHERE user_id = 123 AND status = 'paid' LIMIT 10;<br><br>SELECT VARIABLE_VALUE INTO @final_reads FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads';<br>SELECT VARIABLE_VALUE INTO @final_requests FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests';<br><br>SELECT (@final_reads - @init_reads) AS physical_reads,<br> (@final_requests - @init_requests) AS logical_reads,<br> ((@final_requests - @init_requests) - (@final_reads - @init_reads)) AS cache_hits;
为什么 Handler_read_* 不等于物理读
Handler_read_first、Handler_read_key、Handler_read_next这些状态变量统计的是存储引擎接口调用次数，完全在内存中发生。哪怕 Buffer Pool 里全有数据，它们也会涨；反过来，Buffer Pool 命中率低时，它们可能很小，但磁盘 IO 却很高——因为大量页要从磁盘载入，而载入动作本身不触发这些 handler 计数。
常见误判场景：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 看到
Handler_read_rnd_next高，就以为“SQL 在扫磁盘”：其实它只表示“按行指针取下一行”，取的可能是刚从磁盘读进来的页里的下一行，也可能是 Buffer Pool 里早已存在的页 - 监控显示
Innodb_buffer_pool_reads每秒几十次，但Handler_read_*几乎为 0：说明查询逻辑简单、遍历少，但 Buffer Pool 不够，每页都要单独从磁盘拉，IO 瓶颈藏在这里 -
Handler_read_rnd高 +Handler_read_next低：大概率是ORDER BY无法复用索引，触发了filesort，后续回表随机取行
performance_schema 能否替代全局状态差值法
可以，但更重、更难用。核心路径是盯住events_waits_history_long中wait/io/file/innodb/innodb_data_file事件——每次匹配行代表一次read()系统调用，≈ 至少一页物理读。
限制条件很实在：
- 必须提前开启相关 consumer：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME LIKE 'events_waits%'; - 必须知道目标线程 ID，通常得在执行 SQL 前用
SELECT THREAD_ID FROM performance_schema.threads WHERE PROCESSLIST_ID = CONNECTION_ID()捕获 -
events_waits_history_long默认只保留最后 10000 条事件，高并发下容易被冲掉；events_waits_summary_by_thread_by_event_name是聚合视图，无法还原单条 SQL 的精确页数 - 返回的
TIMER_WAIT是皮秒单位，除以1000000000得毫秒，但真正有用的只是匹配行数，不是耗时
哪些情况会导致逻辑读/物理读统计失真
差值法看着简单，实际很容易踩坑：
- SQL 执行期间有其他线程也在读同一张表，尤其 DML 操作（如
INSERT、UPDATE）会触发页加载、刷脏、合并操作，污染Innodb_buffer_pool_reads计数 - 使用了临时表（
Using temporary）或磁盘排序（Using filesort），其 IO 会计入全局变量，但不属于原 SQL 的“数据页读取”范畴 - 开启了
innodb_change_buffering（默认 ON），插入/更新非唯一索引时延迟写入，可能让后续查询的物理读看起来偏高 - 执行过程中触发了
FLUSH TABLES或RESET MASTER等管理命令，会重置部分状态变量，导致差值归零或跳变
最常被忽略的一点：Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests这个比值，必须在 MySQL 启动并预热 10–20 分钟后再看。刚启动时 Buffer Pool 几乎为空，所有读都是物理读，此时比值毫无参考价值。
