今天把这个问题彻底想通了。连接条件下推这件事我在SQL优化器这个领域里摸爬滚打了不短时间一直觉得它简单——所谓下推不就是把条件往数据源挪一挪让数据早一点被过滤掉吗直到一个线上慢查询把我按在地上摩擦才意识到“基于代价的连接条件下推”这八个字里真正难的不是“下推”而是“基于代价”这四个字背后的判断力。同一个连接条件在这个表上该下推在那个表上就不能下推今天这个统计信息下推是正收益明天数据分布变了下推反而成了负收益。这篇内容就是围绕这个问题的完整复盘。我会先讲清楚连接条件下推到底在优化器里扮演什么角色然后重点拆解为什么不能无脑下推、代价是如何被估算的、选择率和基数在这些决策里起什么作用最后给出一套可以直接落地的最小代价决策流程。无论你是做数据库内核研发、搞SQL性能调优还是单纯对优化器原理感兴趣的开发者这篇文章都能帮你在“下推”这个动作面前建立起自己的判断框架而不是人云亦云。1. 连接条件下推到底在解决什么问题1.1 一个最简单的下推场景先看一条最普通的SQLSELECT * FROM orders o JOIN customers c ON o.customer_id c.id WHERE o.status PAID;这条查询里有一个连接条件o.customer_id c.id还有一个基表过滤条件o.status PAID。如果优化器什么都不做执行计划可能长这样先把 orders 全表和 customers 全表读出来在连接算子层面做匹配最后才把status PAID的条件套上去。这意味着订单表里那些PENDING、REFUNDED状态的行明明是垃圾数据却要白白参与一次连接运算。条件下推要做的事情就是把这个o.status PAID从连接算子的上层一路挪到 orders 表的扫描节点上。执行计划变成先扫描 orders只保留已支付订单再去和 customers 做连接。听上去很朴素但这一个挪动往往能把参与连接的数据量缩小几个数量级代价直接从“全表扫描加全量连接”变成“小数据量过滤加局部连接”。1.2 为什么下推能带来数量级的收益下推的收益本质上是把“过滤”这个操作尽量往数据源头移。数据库存储引擎在扫描数据页的时候本来就要逐行读取、逐行判断格式和可见性此时多判断一个status PAID几乎不增加额外成本。但同样一个条件放在连接算子之后问题就大了每一行数据都得先经过哈希表的构建、探测、内存拷贝然后才轮到这个条件去过滤。过滤越晚被无效数据拖累的环节就越多。我见过一个特别典型的案例。某电商业务有一张大表两亿行订单流水另一张小表是十万行的地区维度表。业务查询要统计特定地区、特定状态的订单金额汇总。未做下推时Hash Join 要拿两亿行去建哈希表内存吃紧直接落盘查询跑了三分钟。把地区和状态下推到大表扫描层之后参与连接的数据量从两亿行骤降到几十万行查询耗时掉到两秒以内。这个例子很直观下推解决的不是单点计算速度而是把无效数据挡在连接运算之外。1.3 下推不是万能的三种典型反例但下推并不总是最优解这恰恰是“基于代价”存在的意义。下面三种情况里无脑下推会吃大亏第一种下推导致索引失效。假设 orders 表上有一个联合索引(customer_id, status)查询条件是o.customer_id c.id AND o.status PAID。如果把status PAID下推成扫描层的独立过滤优化器可能选择走customer_id单列索引回表而不是直接用联合索引做索引覆盖。这种情况下下推反而把一个完美的索引覆盖计划拆成了“索引查找加回表”I/O 直接翻倍。第二种下推改变了驱动表选择。连接顺序的选择依赖于每一侧参与连接的行数估计。如果强制把某个条件下推到左表可能导致优化器觉得左表数据量很小从而选择左表作为驱动表但实际上右表过滤后的数据量更小、连接效果更好。下推动作本身会扰动基数估计进而影响整个连接顺序的搜索空间。第三种下推引发大量重复过滤。当同一个过滤条件在连接结果上原本只需要判断一次下推到基表后却要在分区裁剪、谓词传递等多个环节重复判断虽然单次判断不贵但在分区数量极大的表上这个开销会被放大到不可忽视。所以下推是一个需要被“审判”的候选计划而不是一个默认动作。2. 从“规则下推”到“代价下推”优化器的思维转变2.1 规则优化为什么不够用早期优化器做过一种很朴素的尝试把所有能下推的条件全部下推尽量让扫描层过滤更多数据。这种做法叫规则下推它简单、直接、容易实现。问题是它只能回答“能不能下推”不能回答“该不该下推”。在数据分布均匀的教科书场景下规则下推几乎总是好的因为过滤永远早比晚好。但真实世界的数据分布从来都不是均匀的索引、分区、统计信息、连接顺序这些因素交织在一起导致下推在某些场景下是负优化。规则优化最大的盲区是它对“代价”没有感知。它不知道当前表有几个数据页、不知道某一列的基数有多高、不知道走索引和走全表扫描的差距有多大。它就像一个只会往前冲的士兵不考虑战场地形。2.2 代价模型要回答的三个问题要把下推从“规则”升级为“代价”优化器需要回答三个问题第一个问题下推之后扫描层能省多少这取决于过滤条件的选择率。如果条件能把一亿行过滤到一百行省下的扫描成本非常可观如果条件本身过滤不了多少数据省下的就有限。第二个问题下推会不会增加额外开销比如前面提到的索引失效、分区裁剪路径变化、表达式重复计算这些都是下推的“隐藏成本”。如果额外开销大于过滤收益下推就亏了。第三个问题下推对上层连接算子有什么影响连接算子的代价和输入行数是强相关的。哈希连接构建阶段的开销、探测阶段的比较次数都随输入规模线性或近似线性增长。下推后输入变小连接阶段自然受益但受益多少取决于连接算法和另一侧输入的大小。2.3 判断下推收益的核心公式我在实际评估下推收益时习惯于把代价拆成两部分来看不下推总代价 扫描A全表代价 扫描B全表代价 连接算子处理(A, B)的代价 下推后总代价 过滤A数据代价 扫描B全表代价 连接算子处理(σ(A), B)的代价如果下推后总代价 不下推总代价才选择下推否则保留原计划。这个公式虽然看着简单但它把决策拆成了可计算的模块。实际落地时还要在这个基础上乘系数、加阈值避免微小收益导致执行计划频繁抖动。这里补一个我自己的经验不要在收益小于10%的情况下执行下推。因为代价模型本身有估算误差如果收益只有三五个百分点执行计划切换的稳定性收益远小于风险。给下推动作设置一个“收益阈值”是生产环境里非常重要的一步。3. 代价估算的关键环节选择率与基数3.1 选择率估算从统计信息到直方图代价估算的上游是基数估计而基数估计的上游是选择率计算。所谓选择率就是一个过滤条件能筛掉多少比例的数据。比如o.status PAID的选择率是 0.1意味着扫描层预计会保留 10% 的订单行。最基础的选择率估算逻辑是等值条件按列的 NDV去重值数量来算选择率 ≈ 1 / NDV。如果某列只有 10 个不同值等值条件的粗略选择率就是 0.1。但这个估算只有在数据分布均匀时才算得准。真实数据里经常出现“1000 个值里有一个值占了 90% 的行”这时候用 1/NDV 估算会导致严重偏差。解决分布不均匀问题靠的是直方图。直方图把列值按值域切分成若干个桶每个桶记录行数占比和边界值。查询优化器在估计范围条件、等值条件的选择率时直接查直方图桶的累计频率精度比简单的 1/NDV 高一个量级。做代价下推评估时如果某个连接条件下推后依赖的过滤列有直方图决策质量会明显更好。3.2 连接基数的三种估算方法连接条件下推最终影响的不是单表过滤基数而是连接结果的基数。连接基数的估算方法直接决定下推收益判断的准确性。第一种是基于 NDV 的简单估算对于连接条件A.k B.k估算连接结果行数为|A| × |B| / max(NDV(A.k), NDV(B.k))。这个公式假设两列的值域均匀分布且相互独立适合快速粗略评估但不适合数据倾斜场景。第二种是基于直方图的联合估算同时拿到 A.k 和 B.k 的直方图按桶对齐计算每个值域区间内的匹配行数。这种方法能捕捉局部分布特征对倾斜数据友好但需要存储更详细的统计信息计算开销也更大。第三种是基于采样的实际估算在真实数据上做随机采样直接计算连接选择性。这个方式最准但采样成本高通常只在统计信息缺失或者查询特别复杂时使用。3.3 估算误差如何影响下推决策连接基数估算误差是会传导的。基数的误差会传导到代价估算代价估算的误差会传导到下推决策。常见的情况是优化器高估了下推后的过滤效果觉得收益巨大于是选择下推结果真实数据里过滤列的选择率远没有统计信息显示的那么低下推后扫描层没省多少数据反而因为索引失效把计划搞得更慢。所以在设计基于代价的下推决策器时我强烈建议对估算结果做一个“误差包络”把下推收益算出来之后再假设选择率偏差 2 倍、5 倍、10 倍看下推是否依然有正收益。如果偏差 5 倍就变成了负收益说明这个下推决策很脆弱生产环境里宁可保守一点。4. 实操实现一个最小可用的代价下推决策器4.1 需要哪些输入数据做这个决策器不需要一套完整的数据库内核把关键输入数据准备好就能验证逻辑。你需要的东西有表的基础统计信息行数、数据页数、每行平均宽度、列的统计信息NDV、直方图、空值率、索引信息有哪些索引、索引列顺序以及当前查询的语法树或逻辑计划。我当时做验证时直接用了一个开源OLTP数据库的统计信息表外加一条能产生连接查询的SQL手工解析出谓词。这里的核心点不是工程实现而是先跑通“条件解析 → 基数估算 → 代价比较”这条链路。4.2 代价评估主流程下面这套流程我在多种场景下实测过可以作为最小可行版本的骨架1. 解析连接条件提取所有可下推的谓词 2. 对每个谓词做语义安全检查外连接、反连接场景尤其要小心 3. 查询表的统计信息获取行数、NDV、直方图 4. 计算谓词下推后的扫描行数估计值 5. 估算下推前后连接算子的输入规模与代价 6. 比较下推前后总代价设置收益阈值决定是否下推第4步是关键。假如连接条件是o.customer_id c.id维度表 customers 上还有一个过滤条件c.country CN那么通过谓词传递闭包可以推导出o.customer_id也只会取到满足country CN的那些 id。此时下推的就不是原始连接条件而是由连接条件推出来的“半连接等价谓词”下推后大表扫描可以直接过滤掉大量不可能匹配的行。4.3 决策逻辑与参数调优决策逻辑本身不复杂复杂的是参数调优。我这里给一份我常用的伪代码方便你直接改成自己的实现def should_pushdown(plan, predicate, stats, threshold0.10): # 1. 估算不下推时的总代价 cost_without estimate_cost(plan, predicate_applied_lateTrue) # 2. 估算下推后的总代价 cost_with estimate_cost(plan, predicate_applied_lateFalse) # 3. 计算收益比例 benefit (cost_without - cost_with) / cost_without # 4. 收益低于阈值时不下推保证计划稳定性 if benefit threshold: return False # 5. 做误差包络验证收益足够稳健才下推 if estimate_with_sampling_error(plan, error_factor2.0) threshold: return False return True这个伪代码里的两个细节是我踩过坑之后才加上的一个是收益阈值另一个是误差包络验证。没有这两个保护机制基于代价的下推很容易在数据分布变化时做出错误决定。代价模型里还有一个很重要的参数是 IO 代价和 CPU 代价的权重比。传统数仓里 IO 代价权重高全表扫描的代价要乘以较大系数内存数据库里 CPU 代价更敏感扫描和计算的权重需要重新标定。不同业务负载下这两个权重的比例甚至可能差出两个数量级。5. 真实世界里的坑与排查实录5.1 统计信息过期导致下推误判这是我在生产环境遇到最多的问题。有一张大表每天新增几百万行但统计信息采样任务因为凌晨的批量任务冲突三天没跑。结果优化器拿着三天前的 NDV 和直方图估计选择率把一个本应该下推的高收益条件判定为“收益不足”计划走了全量大表连接线上查询变慢。排查这类问题的思路是如果发现某个查询的下推行为突然变化先看统计信息什么时间更新的再看两版统计信息里目标列 NDV 是否有数量级变化。我个人的建议是对数据量变化快的表设置自适应采样频率或者在查询层面定期抽查执行计划是否有异常回退。5.2 索引失效与下推的博弈前面提到过下推导致索引失效的案例这里展开讲一下。具体场景是这样的一张流水表上有联合索引(tenant_id, status, created_at)查询条件里同时有tenant_id 1和status PAID。代价决策器评估时发现把status PAID下推到扫描层能提前过滤。但问题在于扫描层一旦把 status 作为独立的过滤条件优化器在搜索执行计划时就不再把联合索引看作“完全匹配”而可能退化成只用tenant_id做范围定位再回表过滤 status。这种情况下下推的逻辑收益变成了真实的 I/O 损失。我现在的处理方式是在代价模型里加入“索引匹配度”这个变量。下推前先检查目标列是否在某个索引的前缀列上如果是下推决策要把索引退化成本计算进去。宁可保守一点也不要为了理论收益牺牲实际 I/O。5.3 外连接下推的语义陷阱内连接条件下推相对安全但外连接场景下一定要谨慎。拿 LEFT JOIN 举例右表的过滤条件如果放在 WHERE 子句里它已经不再是一个简单的外连接过滤条件而是会改变连接结果的语义——右表不满足条件的行要被彻底剔除而不是保留 NULL 扩展行。连接类型WHERE 条件下推到右表ON 条件下推到右表推导出的条件下推到左表INNER JOIN安全安全安全LEFT JOIN不安全安全安全但需注意输出补偿RIGHT JOIN不安全安全安全但需注意输出补偿FULL JOIN不安全不安全不安全这张表是我踩坑踩出来的。有一次线上查询用 LEFT JOIN 关联订单表和用户扩展表优化器把 WHERE 里针对用户扩展表的过滤条件下推到了右表结果大量本应保留左表行的查询结果凭空消失。那一次事故让我明白基于代价的前提是语义正确下推的安全性检查永远要排在代价估算之前。5.4 参数化查询与下推失效还有一个容易被忽略的问题是参数化查询。使用绑定变量时优化器在硬解析阶段拿不到具体的参数值也就没法准确估计选择率。很多优化器退而求其次用列的平均选择率来估算但这会让下推决策变得不稳定同一个查询模板参数 A 下推是正收益参数 B 下推就是负收益。针对这个问题我见过的最好方案是“参数化条件的选择率峰值估算”。具体做法是对绑定变量使用历史上出现过的最大选择率来做保守估计。如果在这个保守估计下下推依然有正收益才生成带下推的执行计划。虽然这样做会放弃一部分参数下的最优性能但避免了执行计划在两个极端之间震荡整体的稳定性收益远大于局部性能损失。6. 这个主题还能往哪个方向延伸连接条件下推搞明白之后你会发现它和查询优化里其他几个主题是通的。谓词传递闭包的推导能力、半连接与反连接的改写规则、外连接消除与补偿逻辑这些本质上都是“基于代价选择执行策略”在不同算子上的投影。我自己做实验时还想明白了一个更远的延伸点下推决策和物化视图的匹配是同构问题。物化视图匹配本质上是判断一个查询是否可以被已有物化结果覆盖需要评估重写前后代价的差异连接条件下推则是判断一个谓词是否可以移动到更底层同样需要评估移动前后代价的差异。两者共用一个“逻辑改写 代价验证”的框架。理解了这个同构关系看很多优化器的代码都会豁然开朗。如果你继续深入我建议下一步研究“多谓词联合下推”的问题。单条件下推是简单的但多个条件同时存在时下推顺序不同、下推组合不同产生的计划成本差异极大。这个方向业界也还没有统一答案属于优化器里少有的还能“做出一点新东西”的角落。