第7章 分布式查询优化

第7章 分布式查询优化

本章跟着一条线走：数据一致、系统可用之后，最后一公里的追求是"跨节点查询还得快"。这条线从"怎么把一条全局查询拆成一堆可在各节点执行的局部子查询"（规划）讲起，到"让数据尽量少搬、过滤尽量下推"（传输与下推），再到"联表怎么配才省钱"（三类 Join）。三步走完，分布式查询的优化思路就齐了。

本章路线图

一条主线

单机数据库里，"快不快"看索引和优化器；分布式数据库里，又多了一个全单机没有的变量——网络开销。一条查询慢，很多时候不是 CPU 不行，而是"把该搬的数据搬上半天"。这一章主线就是跟"在数据在节点之间怎么流动更省钱"这件事较劲：先把一条全局 SQL 拆分成"各节点各算各的局部查询 + 一个汇总节点做归并"，再通过下推过滤把"不必搬的数据"卡在源头，最后在联表时用不同策略决定"谁往谁那儿搬、搬多少"。整章一句心法：能本地算的别跨节点，能少搬的别多搬。

沿途站点

• 7.1 分布式查询规划：全局 SQL 如何被拆成局部子查询并配一个汇总器。主线推进到：查询被拆开、往各节点分派。
• 7.2 数据传输与下推优化：用谓词下推、列裁剪把传输压到最小。主线推进到：数据搬家被"源头就过滤"卡住。
• 7.3 分布式 Join 策略：Broadcast、Shuffle、Colocation 三种联表，各在什么时候最省钱。主线推进到：联表也在算“谁搬、搬多少”的经济账。

拐点与结论

本章最关键的认知转折是：分布式查询优化的重心不在"快"，而在"少"——尤其是网络上的少。单机优化靠索引和缓存抢毫秒；分布式优化靠"把传输量最小化"省下成阵毫秒。一旦你把衡量的尺子从"CPU 快不快"换成"数据搬了多少"，下推、裁剪、Join 选型这些手段就都有了统一的解释。这也是为什么我们会反复用"搬数据"这个词。

读完你应该

1. 描述一条全局查询被拆成"局部子查询 + 汇总器"的过程。
2. 说明谓词下推和列裁剪为什么能显著减小跨节点传输。
3. 比较 Broadcast、Shuffle、Colocation 三种 Join 的适用场景与代价。

一个随手可用的判断顺序

落地时遇到一条很慢的分布式查询，别急着怪硬件，按这个由低到高的顺序排查一遍：先看有没有把过滤下推到各分片——很多"慢"其实是把不该搬的行全码到一个节点才过滤；再看有没有做列裁剪——扫描时只挑受查的列，别把整行整列拉来归并；然后看 Join 用了哪种策略——小表该广播却错用了 Shuffle，传输量立刻翻几倍；最后才考虑索引与机器。这套顺序的本体就是本章那句心法"能本地算的别跨节点，能少搬的别多搬"的展开版，它比背任何具体算法的实现都更能救你真的线上问题。

一张把"少"落到三类手段的表

当你说"查询要快"，落到分布式里其实是三件可以分开建设的功夫，用一个表格帮你把本章的每一节归位：

这张表的用处是：遇到一条慢查询，先把慢在"跨太多"还是"搬太多"归因清楚，再对症去对应小节找解法，比囫囵背算法有效。

下一章的接力

原理与优化都备齐了，该看看这些在真实产品里长什么样了。第 8 章把前七章装进一个一个名字——NewSQL 的 TiDB/CockroachDB、NoSQL 的 Cassandra/MongoDB、云原生与 OLAP 的 Aurora/ClickHouse——用真实系统把整套知识落地，并收尾到选型判断。第 7 章的优化追求，最终要服务于"真实业务挑哪个库"；而这里反复出现的"撮合传输量"视角，恰好是判断第 8 章每个阵营"快不快的底气在哪儿"的一把现成尺子。