1. 为什么分布式数据库必须聊算子下推1.1 数据库算子和图像 kernel 算子不是一回事“算子”这个词在不同的技术圈子里含义完全不同。做图像处理的人张口就是 sobel 算子、canny 算子、拉普拉斯算子做 AI 加速的人关心的是 GPU 上的 kernel 算子比如怎么把 matmul 和一个 prelu 融合成一个 kernel减少显存读写而在 PolarDB-X 这类分布式数据库里算子指的是 SQL 执行计划里的一个个执行节点比如扫描、过滤、聚合、连接、排序。很多人第一次看执行计划时被“算子”这个名词唬住了其实它就是一次查询被拆解后的最小执行步骤。PolarDB-X 是兼容 MySQL 生态的分布式数据库对外提供完整的 SQL 能力但底层的数据是分散在多个数据节点上的。一条查询经过解析、优化之后会被翻译成一棵由各种算子组成的执行计划树。算子的排列方式直接决定了数据在计算节点CN和数据节点DN之间怎么流动也决定了这个查询是毫秒级返回还是拖到超时。分布式数据库的慢 SQL 优化很大程度上就是在琢磨这棵算子树怎么排、哪些算子能放到 DN 上去执行、哪些必须拉回 CN 才能算出来。我做性能排查时发现很多团队习惯了单机 MySQL 的思维总觉得 SQL 写得没错就行。可换到 PolarDB-X 之后同样一条 SQL因为缺少“下推”的条件执行时间可能差出几十倍。这篇文章就把算子、下推、执行计划和排查技巧串起来讲一遍帮大家把分布式 SQL 的调优思路理清楚。1.2 算子下推解决的核心问题流量与并行度分布式数据库天生有一个矛盾用户从逻辑上看到的是一张表但这张表的数据是打散在多个物理分片上的。拿订单表举例如果有 1 亿行数据按照 order_id 分片成 64 个分片那么每个分片里大约只有 150 万行。查询如果只按照某个 order_id 精确过滤理想情况只需要访问一个分片但如果要统计全量订单就需要所有分片一起参与计算。这个时候“下推”就变得极其关键。算子下推简单说就是把原本要在计算节点 CN 上做的过滤、投影、聚合、连接等操作尽量放到数据所在的 DN 上去执行。DN 底层是一个完整的 MySQL 引擎完全有能力做局部计算。如果非要把所有原始数据先拉到 CN再开始过滤和聚合网络传输量会变得非常恐怖。打个比方你在全国有 64 个仓库现在要统计每个仓库的库存总量。最省钱省时的办法是让每个仓库自己先清点一遍然后只把“仓库编号总数”报到总部。如果反过来把每个仓库里的每一件货都运到总部再清点不光运费贵总部也根本忙不过来。数据库里的算子下推解决的就是这种“货物运输”问题。它让每一个分片在本地完成尽可能多的计算只把中间结果上抛这样既省网络带宽也降低 CN 的 CPU 和内存压力。下推还能带来另一种收益并行度。每个 DN 并行处理自己手里的分片数据计算压力被自然分散到多个物理节点上。这和 AI 训练场景里“大量使用算子对硬件性能的挑战”是一样的道理一旦算子过多、数据搬运过多硬件的访存和通信就会成为瓶颈。数据库也一样算得再快不如少搬点数据。2. 常见算子的分类与可下推性判断2.1 从执行计划看算子全家桶一条 SQL 从语法树变成可执行计划PolarDB-X 里会出现不少算子。虽然名字多但按功能其实可以分几类扫描算子逻辑上叫 LogicalView负责定位具体分片并包装底层对物理表的扫描。执行时它会给 DN 生成一条真实的 SQL告诉 DN 要读哪张表、走哪个分片。过滤与投影算子Filter 负责执行 WHERE 条件过滤Project 负责列裁剪、表达式计算和别名处理。这两个算子多数情况下会跟扫描一起下推。聚合算子常见的是 HashAgg 和 SortAgg负责 GROUP BY、COUNT、SUM、AVG 这类操作。分布式环境下聚合经常被拆成两段下推到 DN 的 partial 聚合以及留在 CN 的 final 聚合。连接算子HashJoin、NestedLoopJoin负责多表关联。能不能下推是分布式 join 优化里最讲究的地方。排序与分页算子Sort 和 Limit负责 ORDER BY 和 LIMIT涉及局部排序和全局排序之间的取舍。交换算子Gather 和 Exchange负责把多个 DN 的结果汇集到 CN或者在做重分布时把数据重新打散。Gather 是分布式计划里最敏感的一个算子Gather 出现的位置基本决定了数据要传输多少。写 SQL 的人可以不知道这些算子的名字但做性能调优的人必须学会看它们。“这个计划里 Gather 后面接了什么东西”是我排查分布式 SQL 时第一个问自己的问题。2.2 哪些算子能下推哪些必须留在 CN算子能不能下推没有一个绝对不变的答案核心逻辑就看两条下推之后语义是否仍然正确下推之后数据搬移是否真的减少。我把常用的判定规则整理成了一个表算是入门参考。算子能否下推关键条件原因Filter通常能下推过滤条件能写进发给 DN 的 SQLWHERE 本身就是为了过滤数据越早过滤越省流量Project通常能下推表达式在 DN 侧可计算剪列和简单表达式下推能减少每行数据的字段数Agg部分下推拆成 partial final 两段每个 DN 先做本地分组聚合CN 只汇总分组结果Join要看数据分布两表分片键一致且是等值关联同分布 join 能在 DN 内完成否则需要把数据拉到 CN 重分布Sort部分下推每个分片可以局部排序但全局有序需要 CN全局排序必须拿到全量数据才能保证顺序Limit有条件下推没有全局排序时可以先在各分片各取 Limit 数量配合全局排序时需要把 Limit 推到 Sort 之后重新计算这个表只是基础。实际操作时PolarDB-X 的优化器会做代价估算综合判断每个算子放到哪一侧更划算。比如一个 GROUP BY下推 partial 聚合之后CN 的 final 聚合只需要处理“分片数×分组数”量级的数据而不是全表行数。当表行数过亿时这个收益是数量级上的差别。还有一点要留意一个算子下推不代表整棵计划都下推了。很常见的情况是 Filter 和 partial 聚合都下推了但一个跨分片 join 导致大量数据从各 DN 汇集到 CN之前的收益全部被冲掉。所以看执行计划时我习惯先找 Gather再观察 Gather 下面压着多少个算子。2.3 算子融合减少节点间数据搬运的另一种手段除了把算子下推到 DN数据库引擎本身还会做算子融合。比如连续多个 Filter 和 Project如果逐个执行每个算子都要遍历一遍数据增加表达式求值的开销。优化器会把它们合并成一个复合算子让一条数据经过一次计算就完成多步操作这其实和 AI 场景里的算子融合思路很像。很多做 GPU 算子开发的同学都知道一个 kernel 里如果能融合 matmul 和 prelu就能减少一次中间结果的写回和读取。数据库同样如此把相邻的过滤、投影、条件判断合并起来能减少表达式重复计算也能让 CPU 缓存更友好。PolarDB-X 在生成物理计划时会主动做一些这样的 merge。虽然这部分不如“下推”那么显性但它对硬件性能的挑战同样存在尤其在数据量大、算子链又长的场景里少一次数据扫描就是实打实的性能提升。3. 如何看懂执行计划并验证下推效果3.1 从一个 EXPLAIN 开始在 PolarDB-X 中最直接的验证手段就是执行 EXPLAIN。我拿一个常见的订单汇总查询举例EXPLAIN SELECT o_custkey, SUM(o_totalprice) FROM orders WHERE o_orderdate 2024-01-01 GROUP BY o_custkey;假设 orders 表是分布式表查询条件里的 o_orderdate 不是分片键优化器会扫描所有分片但会把过滤和分组聚合同时下推。简化后的执行计划看起来是这个样子实际输出会更完整但结构上差不太多Gather(concurrenttrue) LogicalView(shard_id0, sqlSELECT o_custkey, SUM(o_totalprice) FROM orders WHERE o_orderdate 2024-01-01 GROUP BY o_custkey) LogicalView(shard_id1, sqlSELECT o_custkey, SUM(o_totalprice) FROM orders WHERE o_orderdate 2024-01-01 GROUP BY o_custkey) ... HashAgg(final) Gather LogicalView(...)这里最值得关注的是 LogicalView 里那一长段 SQL。只要它包含了 WHERE、GROUP BY 和 SUM就说明 Filter 和 partial 聚合都成功下推到了 DN。CN 上的 HashAgg(final) 其实很轻它只需要处理 64 个分片返回回来的“客户号小计”。如果这个查询完全没下推聚合你会看到一个非常夸张的 GatherLogicalView 只负责把 orders 表的数据一股脑往上抛Gather 之后才接 HashAgg。两种计划放在 1 亿行的表上区别就是“传输 1 亿行”和“传输几万个分组记录”的区别。3.2 通过 EXPLAIN ANALYZE 确认实际行数EXPLAIN 看到的是优化器预计会发生的事EXPLAIN ANALYZE 才能看到真正发生了什么。在 PolarDB-X 里执行 explain analyze会把每个算子的实际输出行数和耗时打出来。我通常会重点盯住 Gather 算子的输出行数。比如一个按非分片键做的 GROUP BY查询里用 o_custkey 分组如果下推生效Gather 的输出行数约等于全局分组数。假设有 64 个分片每个分片返回 2 万个分组Gather 输出大约会是 2 万量级不会超过“分组数×分片数”。如果下推失效Gather 的输出行数约等于全表扫描行数可能是几百万行。这两条结论的正向和反向差别极其明显。所以每次有人问我“怎么判断 PolarDB-X 到底下推没下推”我的标准回答都是别猜执行一下 EXPLAIN ANALYZE看 Gather 算子的实际输出行数比看任何解释文章都直观。3.3 从 LogicalView 里的 SQL 判断下推粒度还有一个很实用的技巧就是看 LogicalView 节点里携带的那条 SQL。PolarDB-X 的分布式执行计划会在 LogicalView 里展示它要发给 DN 执行的完整语句。这条语句的粒度直接暴露了下推的深度。举个例子。一个只查单分片的点查SELECT * FROM orders WHERE order_id 10086;如果 orders 表按 order_id 分片执行计划里 LogicalView 可能只有一个 shard_id并且 SQL 里保留着 order_id 10086 的条件。这说明扫描已经被裁剪到单个分片是最高效的下推形态。如果查询变成SELECT * FROM orders WHERE o_orderdate 2024-06-01;因为 o_orderdate 不是分片键LogicalView 里会出现多个 shard_idSQL 里同样有过滤条件。下推依然有效每个分片只返回当天的数据但扫描范围不再是单分片。这时候“下推”做到了但“裁剪”没做到传输量还是可能不小。我排查问题时会把 LogicalView 里的 SQL 单独复制出来拿到底层 DN 上手动执行一次看看它本身有没有走合适的索引。这一步经常能区分出两个不同的问题到底是“算子没下推”还是“DN 侧本来就慢”。前者是分布式计划的问题后者是普通 MySQL 索引优化的问题不能混在一起。4. 实操让算子下推发挥作用的调优套路4.1 写 SQL 时的四个前置条件优化器再强也需要 SQL 本身给机会。我整理了四个非常关键的写法能帮优化器更容易生成下推计划。第一过滤条件尽量带上分片键等值条件。分片键等值条件可以让优化器直接裁剪到某个分片LogicalView 里的 shard_id 数量会大幅减少。这里的重点不只是下推过滤而是让扫描本身就变小。例如表按 order_id 分片查询条件写 order_id 10086就只需要访问一个分片写 order_id IN (10086, 10087)可能需要访问两个分片。如果条件里完全不含分片键所有分片都会被访问扫描范围降不下来。第二避免在分片键或关联键上套函数。常见写法是 WHERE order_id 1 10086或者做 join 时在关联字段上套 TO_CHAR、DATE_FORMAT 之类的函数。函数包裹会让优化器失去对分片键的推导能力无法裁剪也会影响下推。这个坑非常容易踩因为业务需求里经常要按日期格式化、按字符串拼接等写的时候很顺手性能问题留到了后面。第三分布式 join 要优先使用同分布键。所谓同分布就是两张表按同一个字段、同一个规则分片。比如 orders 和 order_line 都按 order_id 分片那么 orders JOIN order_line ON orders.order_id order_line.order_id 时每个分片上的本地数据已经满足关联条件优化器可以把整个 join 下推到 DN 执行。反之如果两张表的分片键不一致就必须通过 Gather 把其中一个表的数据拉回 CN再做重分布或广播这种 join 很难下推。第四全局聚合的中间结果要越少越好。当 GROUP BY 的字段不是分片键时partial 聚合虽然能下推但分组数依然可能很大。如果能在 SQL 层面先缩小数据范围比如只保留最近一年的数据效果会非常明显。这是“下推”之外同样重要的事下推负责减少传输过滤负责减少数据量两者叠加才是完整的优化。4.2 用改写解决一个不下推的案例之前帮朋友看过一个典型的慢 SQL业务场景是查每个客户最近的一笔订单。订单表 orders 有 8000 万行分片键是 order_id但业务上希望按 o_custkey 分组统计。朋友一开始写的版本是这样SELECT o_custkey, o_orderdate FROM orders o WHERE o_orderdate ( SELECT MAX(o2.o_orderdate) FROM orders o2 WHERE o2.o_custkey o.o_custkey );这个写法看起来逻辑很严谨但关联子查询会让优化器很难生成高效的下推计划。执行时整个查询相当于要对每一行都额外做一次子查询分布式环境下代价被进一步放大。我们把它改成了先分组再关联的写法SELECT o.o_custkey, o.o_orderdate FROM orders o JOIN ( SELECT o_custkey, MAX(o_orderdate) AS max_date FROM orders GROUP BY o_custkey ) t ON o.o_custkey t.o_custkey AND o.o_orderdate t.max_date;改写后内层 GROUP BY 能在每个 DN 上做 partial 聚合外层 join 虽然可能还是需要把数据汇集到 CN但数据量已经从全表缩小到了每个客户的最新订单。实际测试下来执行时间从原来的分钟级降到了秒级。这个案例给我的经验是不要迷信“一条 SQL 搞定一切”。分布式数据库里SQL 写法对执行计划的影响比单机数据库大得多因为每一个算子都可能涉及跨节点数据移动。下推不是一个黑盒开关而是优化器基于代价估算的结果。我们要做的所有事情都是尽量让优化器看到“下推会便宜很多”。4.3 广播小表与重分布的取舍不是所有 join 都能做到同分布下推。当两张表的分片键不一致又确实需要关联时PolarDB-X 可能会选择另外两种策略广播小表或者重分布。广播小表的意思是把其中一张行数较小的表复制一份到所有 DN让每个 DN 都能在本地完成 join核心还是减少把大表数据拉到 CN 的代价。判断有没有走广播可以看执行计划里有没有 BROADCAST 或类似的算子。这种方案适合一张表大、一张表明显小的场景比如事实表和维度表关联。维度表通常只有几千行广播成本很低收益却很大。重分布则是把大表数据按照 join key 重新打散。这通常会引入额外的 Exchange 算子意味着一定的网络传输但它比把所有数据都拉到 CN 再 join 要合理。这里没有一个绝对的最优解优化器会根据行数、分片数、网络代价来估算。所以大家在分析计划时不要看到“join 没完全下推”就断定 SQL 一定有问题先看它是否选择了成本更低的广播或重分布方案。5. 常见问题与排查技巧实录5.1 算子下推失效的典型场景合集下面这些场景是我在真实业务里反复踩过、也帮别人排查过的每个都值得收藏。场景现场表现原因建议分片键上做计算LogicalView 全分片扫描Filter 在 CN 执行函数破坏了分片键推导改成等价的“无函数”表达式例如 order_id 10086 - 1两表分片键不一致做 joinGather 之后出现 HashJoin数据分布不满足同分布重新选择分片键或用小表广播子查询嵌套太多计划树很深Gather 附近堆积算子关联子查询难以改写尽量改写成 JOIN或拆成中间结果再关联对可空字段做 NOT IN执行计划退化成 NestedLoop存在 NULL 语义问题用 NOT EXISTS 改写计划通常更容易下推SELECT * 且缺少列裁剪Project 不痛不痒大量列被拉回 CN列过多导致传输放大只查必要字段让 Project 随扫描一起下推全局 ORDER BY LIMIT每个 DN 先传全部排序数据CN 再 Sort 重新取 Limit全局排序无法完全下推用分页时尽量加范围过滤让 Limit 下推更充分其中“两表分片键不一致做 join”是最让人头疼的。分片键在建表时就固化下来后面想改代价很高。所以设计表结构时一定要把高频 join 的关联键放进分片键候选集里。甚至可以在冗余维度表上做文章用空间换时间。5.2 几条亲测有效的排查命令第一用 EXPLAIN 看逻辑计划先找 Gather 位置。如果 Gather 上面还有排序、连接、聚合说明这些操作只能由 CN 完成Gather 下面压着的算子越多说明下推越彻底。我会把计划文本复制出来用搜索功能搜“Gather”然后看它前后各有哪些算子几秒钟就能定位问题方向。第二用 EXPLAIN ANALYZE 看实际行数重点对比 Gather 的输入和输出。一个简单的衡量方式如果 Gather 的输出行数仍然接近全表行数那么大概率有算子没有下推需要回头改 SQL 或表结构。第三结合 DN 侧慢日志确认下推 SQL 的实际执行情况。LogicalView 里会携带一条发给 DN 执行的完整 SQL可以把这条 SQL 单独拿到底层 MySQL 上跑一遍看它自身的执行计划。如果这条 SQL 在 DN 上也走了全表扫描那问题就不在分布式下推而在 DN 侧缺索引。第四遇到拿不准的写法时多做 A/B 对照。把 SQL 里最可疑的部分去掉或改写EXPLAIN 两次看 Gather 位置和估算行数有没有明显变化。这个方法看起来笨但最能帮助建立直觉。开发环境里跑一跑比翻文档有用得多。5.3 一个完整的排查实录再分享一个我近期处理的线上慢 SQL。查询目的是统计某个网点下所有商品最近一周的销量排名SQL 大致如下SELECT item_id, SUM(sale_cnt) AS total_sale FROM sale_detail WHERE shop_id 1001 AND sale_date 2024-07-01 GROUP BY item_id ORDER BY total_sale DESC LIMIT 20;sale_detail 表按 shop_id 分片这个查询带了 shop_id 等值条件所以扫描能裁剪到单个分片理论上应该很快。但实际执行很慢EXPLAIN 看到 LogicalView 确实只带了一个分片问题出在后面 ORDER BY total_sale DESC。由于 order by 的是聚合后的结果CN 需要在 final 聚合后做全局排序但这张表在单分片下局部数据已经满足条件其实可以不这么绕。我们先把 GROUP BY 和 LIMIT 的语义看清楚查询只需要返回销售量最大的 20 个商品但 CN 必须先对全部分组完成排序。在单分片场景下这一步也可以让 DN 本地完成不过最终计划还是把它拿到了 CN。后来我们在 item_id 上调整了索引并且把 SQL 改成先做一次子查询让 DN 先把结果限定到更小的范围再让 CN 做最终排序整体耗时降了将近一半。这个案例让我印象很深因为它说明“下推”要结合数据分布来看。一个查询如果已经被裁剪到单分片那么它本质上已经是单机查询此时即便某个算子显示在 CN 上执行网络开销也不算大真正的瓶颈可能在 DN 本身的扫描和排序成本上。最后说一点我自己的体会。算子下推这件事不光是优化器的事更是前置设计的事。很多团队的慢 SQL表面上能在 SQL 层面优化但根子是建表时把分片键选错了。我在实际项目中见过太多这样的例子订单表和客户表用的是完全不同的分片键但因为业务上要按客户维度聚合订单每次 join 都要跨节点拉数据。后来改成按客户维度的汇总表把统计结果异步写入查询时间从几十秒降到了几百毫秒。所以遇到下推难的 SQL先别急着骂优化器多想想表结构、分片键和查询模式是否匹配。这比任何一条调优技巧都重要也是我在多次踩坑之后最想提醒你的一件事。