嵌套查询导致逻辑读暴增的核心是相关子查询触发Nested Loops，外层每行驱动一次内层扫描，若外层10,000行、内层每次扫2,000行，则总逻辑读达2,000万次；无索引时退化为全表扫描，叠加统计信息误判或视图嵌套超3层致条件下推失效，进一步加剧重复I/O。
嵌套查询本身不改变数据库的写操作次数，但会显著放大读操作量，尤其是逻辑读——多数情况下读写比例失衡不是因为写了更多，而是读得太多、太重复。
为什么嵌套查询会让逻辑读暴增
核心在于执行路径：相关子查询（WHERE t1.x IN (SELECT y FROM t2 WHERE t2.z = t1.w)）天然触发 Nested Loops，外层每行都驱动一次内层扫描。如果外层返回 10,000 行，子查询每次扫 2,000 行，总逻辑读就是 2,000 × 10,000 = 2,000 万次页面访问。
- 子查询没索引时，
Index Seek退化为Clustered Index Scan或Seq Scan，单次扫描成本翻倍 - 优化器误判行数（如
EstimatedRows=100，ActualRows=50000），会导致它选错驱动表，把大表放内层反复扫 - 视图嵌套超 3 层后，SQL Server/PostgreSQL 常放弃条件下推，外层
WHERE条件无法下压到基表，被迫先物化中间结果再过滤
物理读飙升往往暴露缓存失效或计划退化
逻辑读高但物理读低，说明数据还在 buffer pool；两者都高，基本锁定是执行计划缺陷或索引缺失。物理读突增常伴随以下信号：
-
SET STATISTICS IO ON显示某视图调用的physical reads占整条语句 90% 以上 - 执行计划里出现大量
Table Spool（SQL Server）或Materialize（PostgreSQL），且节点下方是全表扫描 - 子查询涉及的表近期有大批量
UPDATE/DELETE，但没ANALYZE，统计信息滞后导致优化器误估
哪些写法会隐式增加写开销
嵌套查询不直接写磁盘，但某些改写方式会触发临时结构，间接抬高写压力：
- MySQL 5.7 中
IN (SELECT ...)可能生成隐式临时表，若tmp_table_size不足，会落盘成MyISAM临时表，产生磁盘写 - PostgreSQL 的 CTE 默认物化（
MATERIALIZED），若子查询结果集大，会写入temp_buffers，甚至 spill 到磁盘 - SQL Server 中标量子查询若未被参数化，可能因
parameter sniffing失败而拒绝重用执行计划，频繁编译+缓存新计划，加重plan cache写压力
真正影响读写比例的，从来不是“有没有嵌套”，而是“嵌套是否被物化”以及“物化时机是否可控”。别急着拆 SQL，先看执行计划里那个子查询节点有没有 Spool、Materialize 或 TempTable 标记——有，就说明读已失控；没有，问题可能出在索引或统计信息上。
