谓词下推是云原生数据库嵌套查询性能的关键，因分片架构下未下推会导致各节点全表扫描、中间结果暴增、网络与内存过载；常见漏推结构包括含union all、广播表子查询及关联子查询，需结合explain analyze与执行时rows_read、cop_task等指标验证是否真实生效。
云原生数据库中嵌套查询不自动下推谓词，很可能导致全量子查询执行、跨节点数据暴增、甚至OOM崩溃——这不是理论风险，而是生产环境高频故障点。
为什么嵌套查询在云原生架构里特别依赖谓词下推
云原生数据库（如PolarDB-X、TiDB、OceanBase分片集群）天然把一张逻辑表拆到多个物理节点上。嵌套查询一旦没下推，子查询就会在每个分片上“盲扫”全量数据，再把结果汇总到协调节点做外层过滤。这直接触发三个硬伤：
- 网络带宽被中间结果集打满，尤其当子查询返回百万行、而外层
WHERE只留10行时 - 协调节点内存吃紧，
Temp table space full或Query execution timeout错误频发 - 分片间无法并行裁剪，本可下推到单个分片的
user_id = 123条件，被迫升格为全局广播
哪些嵌套结构最容易漏掉谓词下推
不是所有嵌套都等价。优化器对以下结构的下推支持度差异极大，需人工干预：
-
SELECT * FROM (SELECT id, name FROM users) t WHERE t.name LIKE '%admin%'：外层WHERE可安全下推到子查询，但部分旧版TiDB需加/*+ PUSH_PRED(t) */提示 -
SELECT * FROM orders WHERE user_id IN (SELECT id FROM users WHERE status = 1)：status = 1必须下推，否则子查询扫描全量users；若users是广播表，下推失效，得改用JOIN -
SELECT (SELECT COUNT(*) FROM logs l WHERE l.order_id = o.id AND l.ts > '2026-01-01') cnt FROM orders o：关联子查询中的时间条件l.ts > '2026-01-01'若不下推，每个o.id都会触发一次全logs表扫描
如何验证谓词是否真被下推了
不能只看EXPLAIN输出里有没有“pushdown”字样——那只是优化器声明，未必落地。关键看执行时行为：
- 用
EXPLAIN FORMAT=VERBOSE（PolarDB-X）或EXPLAIN ANALYZE（TiDB）查子查询节点的rows_read，对比子查询单独执行的行数；如果接近，说明没下推 - 抓包观察分片间传输量：
tcpdump -i any port 4000 | grep -c "SELECT.*FROM.*logs"，若出现大量重复子查询请求，基本确认未下推 - 检查慢日志里的
Exec_detail字段，找cop_task（TiDB）或remote_scan（PolarDB-X）是否携带过滤条件，例如range:[100,100]比range:[-inf,+inf]可信
真正麻烦的是那些“看起来被下推了，实际被优化器悄悄禁用”的情况：比如子查询含UNION ALL且外层有ORDER BY，或下推后破坏了分片键语义。这种边界问题不会报错，只会让查询变慢十倍以上，且监控难以定位。
