SQL 分布式数据库查询优化方法

join 在分布式数据库中慢因缺乏跨节点哈希连接支持，常触发大量数据重分布；应优先将 join 字段设为分片键，必要时强制归并连接，并避免右表无索引的 left join。

为什么 JOIN 在分布式数据库里特别慢

因为大多数分布式数据库（如 TiDB、CockroachDB、Greenplum）不支持跨节点的高效哈希连接，JOIN 往往触发大量数据重分布（shuffle），甚至全表广播。实际执行时可能看到 Exchange 或 RemoteScan 算子占 70%+ 时间。

• 优先把 JOIN 条件字段设为分片键（shard key），让关联行落在同一节点上，避免 shuffle
• 如果必须跨分片 JOIN，用 /*+ TIDB_SMJ(t1, t2) */（TiDB）或 /*+ MERGEJOIN */（CockroachDB）强制走归并连接，比嵌套循环更可控
• 警惕 LEFT JOIN 右表无索引：分布式环境下，右表扫描可能在每个分片都执行一遍，放大 I/O

WHERE 条件下推失败的典型表现

常见现象是执行计划里出现 Selection 节点挂在最外层，说明过滤逻辑没下推到存储层，所有数据先拉到计算层再筛——尤其在 UNION ALL 或子查询嵌套深时高频发生。

• 避免在 WHERE 中对分片键做函数操作，比如 WHERE YEAR(created_at) = 2024 会禁用分区裁剪
• 使用 EXPLAIN FORMAT = 'VERBOSE'（TiDB）或 EXPLAIN (DISTINCT ON)（CockroachDB）确认条件是否出现在 TableReader 或 IndexScan 下方
• 字符串比较注意 collation：utf8mb4_0900_as_cs 和 utf8mb4_general_ci 混用可能导致索引失效，继而阻止下推

聚合查询（GROUP BY / ORDER BY）卡在 HashAgg 阶段

分布式场景下，HashAgg 默认在单个 TiKV Region 上做局部聚合，再由 TiDB 汇总全局结果。但如果分组键倾斜（如 90% 数据的 status = 'pending'），局部聚合后仍要传输巨量中间结果。

• 加 HINT 强制两阶段聚合：/*+ AGG_TO_COP() 把部分 GROUP BY 下推到 TiKV
• ORDER BY 必须带 LIMIT，否则所有节点数据都要传到 coordinator 排序；没有 LIMIT 的分布式排序基本等于拒绝服务
• 避免 GROUP BY 多列且其中一列低基数（如布尔字段），容易引发 coordinator 内存溢出，改用 COUNT_IF 或预计算宽表

为什么 SELECT * 在跨分片查询中风险极高

不只是带宽问题。当表有 50 列、分布在 12 个分片上，SELECT * 会让每个分片都序列化全部字段再网络传输，而实际业务可能只用其中 3 列。更糟的是，某些分布式数据库（如 Citus）会对 * 做隐式列展开，导致 planner 误判统计信息，选错执行路径。

• 永远显式写出需要的列名，哪怕多敲几下键盘
• 如果用 ORM，检查生成 SQL 是否含 *；Django 的 .values()、SQLAlchemy 的 load_only() 是刚需
• 临时调试用 EXPLAIN ANALYZE 时，也别偷懒写 *——它可能掩盖真实瓶颈点

分布式查询优化最麻烦的地方不在语法，而在你根本不知道哪一行 SQL 触发了跨节点广播。查慢查询日志时，重点盯 ExecTime 和 NumRegions 这两个字段，比看执行计划更快定位问题。