子查询在大数据集上易卡死，因数据库常默认用嵌套循环，10万×10万达100亿次比较；需优先用JOIN、加索引、限制子查询结果集、避免函数导致索引失效、分批处理并禁用客户端缓存。
子查询在大数据集上为什么容易卡死
因为多数数据库执行子查询时默认走嵌套循环（Nested Loop），外层每查一条，内层就全表扫一遍。10 万行 × 10 万行 = 100 亿次比较，不是慢，是根本跑不完。
常见错误现象：SELECT * FROM orders WHERE customer_id IN (SELECT id FROM customers WHERE region = 'CN') 在 customers 表没索引、且数据量超 50 万时，可能执行超 2 分钟甚至被 kill。
- 先确认子查询是否真的需要——很多场景用
JOIN更稳，尤其当内外表都有合适索引时 - 如果必须用子查询，确保子查询结果集尽量小：加
WHERE过滤、用LIMIT（仅限非关联子查询）或提前物化（如 MySQL 8.0+ 的WITH临时结果） - 避免在子查询里调用函数（如
DATE(created_at)），这会让索引失效，导致全表扫描
流式处理大结果集时子查询怎么不爆内存
数据库客户端（比如 Python 的 psycopg2 或 Java 的 JDBC）默认把整个结果集拉到内存里。子查询嵌套深 + 数据量大 = 直接 OOM。
使用场景：导出报表、ETL 中间计算、后台定时任务分批同步。
- 禁用客户端缓存：PostgreSQL 中设
cursor_factory=RealDictCursor并用fetchmany(1000)；MySQL 中开游标前执行SET SESSION SQL_BUFFER_RESULT = OFF - 把“子查询”拆成两步：先查主键 ID 列（轻量），再用
IN (id1, id2, ...)分块查详情（注意单次IN不超过 1000 个值，否则解析慢或报max_allowed_packet错） - 别在子查询里用
SELECT *，只选必要字段——尤其避开TEXT/JSON大字段，它们会显著拖慢网络和内存占用
分块执行子查询时 LIMIT OFFSET 为什么越往后越慢
LIMIT 1000 OFFSET 100000 看似分页，实则让数据库扫完前 10 万行才取后 1000 行，I/O 和 CPU 成倍涨。
性能影响：OFFSET 超 5 万后，响应时间常呈指数增长；某些 OLAP 场景下，单次查询耗时从 200ms 暴增至 8s+。
- 改用基于游标的分页（Cursor-based pagination）：用上一批最后的
id或created_at做条件，例如WHERE id > 123456 ORDER BY id LIMIT 1000 - 子查询本身不建议带
OFFSET；如果非要分块，把分块逻辑移到应用层：先SELECT id FROM large_table WHERE ... ORDER BY id流式取 ID，再按 ID 批量 JOIN 或 IN - 注意时序一致性：若数据实时写入，两次分块之间可能漏/重数据，需加时间戳范围锁或业务层幂等处理
MySQL 5.7 vs PostgreSQL 14 子查询优化行为差异
老版本 MySQL 对 IN (subquery) 几乎不优化，而 PostgreSQL 默认尝试将子查询转为哈希连接（Hash Join），但前提是子查询可物化且不相关。
兼容性影响：同一语句在两个库上执行计划可能完全不同，线上迁移或双写时容易翻车。
- MySQL 5.7：优先改写为
EXISTS（尤其当子查询含GROUP BY或聚合时），EXISTS通常比IN快 3–5 倍 - PostgreSQL：用
EXPLAIN (ANALYZE, BUFFERS)看是否走了Hash Semi Join；如果子查询用了窗口函数或 CTE，加MATERIALIZED强制物化，避免重复执行 - 跨库共用 SQL 时，避免依赖
WITH RECURSIVE或LATERAL—— MySQL 8.0 才支持前者，PostgreSQL 9.3+ 支持后者，但语义细节有出入
真正难的不是写对子查询语法，而是判断它在百万级数据、并发 50+、磁盘 I/O 已饱和的生产环境里，到底会触发哪条执行路径。很多问题直到压测第三轮才暴露，因为前两轮数据还没刷出 buffer pool。
