子查询在导出时引发全表扫描、长事务持锁、资源耗尽及分页失效等问题。因其逐行执行、无法流式返回、优化器误估代价且难以分片，导致性能雪崩与超时风险陡增。
子查询在导出时触发全表扫描，导致事务长时间持锁
导出类查询通常需要一次性读取大量数据，而相关子查询（correlated subquery）会让数据库对主表每一行都执行一次子查询。比如：SELECT * FROM orders o WHERE EXISTS (SELECT 1 FROM customers c WHERE c.id = o.customer_id AND c.status = 'vip')，当 orders 表有 500 万行，且 customers 缺少 id 或 status 索引时，实际执行会变成 500 万次独立查询 —— 每次都可能触发全表扫描或索引回表，事务无法快速释放锁。
- MySQL 默认事务隔离级别是
REPEATABLE READ，长事务会阻止 purge 线程清理 undo log，加剧锁等待和内存压力 - PostgreSQL 的
READ COMMITTED虽不阻塞 vacuum，但子查询重复执行仍会放大 I/O 和 CPU 占用 - SQL Server 在导出场景下若使用
SELECT ... INTO+ 子查询，会隐式升级为表级锁，进一步拖慢并发写入
子查询结果集无法流式返回，内存与网络缓冲区被撑爆
大多数数据库驱动（如 JDBC、ODBC）在处理含子查询的 SELECT 时，会先将整个结果集加载到内存再分批发送。子查询若未提前过滤，中间结果集可能远大于最终导出数据量 —— 比如一个 IN 子查询返回 20 万 user_id，主表匹配后只导出 2 万行，但驱动仍需缓存全部 20 万 ID 并做哈希查找。
- Java 的
ResultSet默认 fetch size 是 10，遇到子查询嵌套时容易触发多次 round-trip，超时风险陡增 - Python 的
psycopg2若未设cursor.itersize，fetchall()会把所有行拉进内存，OOM 直接 kill 连接 - 导出工具（如 Navicat、DBeaver）常默认启用“全部加载”，对子查询结果不做分页预估，一卡就是超时
优化器无法准确估算子查询代价，选错执行计划
统计信息滞后或列直方图缺失时，优化器常低估子查询开销。例如：EXPLAIN 显示 rows=100，实际运行扫了 80 万行 —— 因为子查询里用了 LIKE '%keyword%' 或 DATE(created_at)，导致索引失效，但优化器仍按索引可用估算。
- MySQL 8.0+ 的
optimizer_switch='subquery_to_derived=on'可强制将部分子查询转为派生表，但仅对非相关子查询生效 - PostgreSQL 的
enable_hashjoin=off可能让子查询走 nestloop，而实际应走 hash join，需手动 hint 或重写 - SQL Server 的
OPTION (RECOMPILE)对参数化子查询有效，但对硬编码值无效，导出脚本若用字符串拼接就白加
导出场景下子查询无法利用游标分页，只能硬扛全量
Web API 导出常用游标分页（如 WHERE id > last_id LIMIT 1000），但子查询往往依赖聚合或跨表关联，无法简单拆分。比如导出“近 30 天下单且用户等级 ≥ 4 的订单”，子查询算用户等级必须全量扫描 user_history 表，没法按 order.id 切片。
- 强行加
LIMIT到子查询里（如(SELECT ... LIMIT 1000)）会导致逻辑错误：漏掉本该匹配但排在 1000 名之后的用户 - 用临时表存储子查询结果再 JOIN，虽可分页，但临时表建索引耗时、磁盘空间占用高，导出中途失败难恢复
- 物化视图或汇总表是更稳方案，但要求业务允许 T+1 延迟，实时导出场景不适用
子查询在导出中真正难解的点，不是语法多复杂，而是它把“计算时机”和“数据边界”绑死了——你没法告诉数据库“先给我 1000 行主表，再针对这 1000 行跑子查询”，它要么全算，要么不查。
