mysql 8.0+ 的 partition by 对 join 无直接加速作用，仅当分区键与 join 条件字段一致、分区键有索引且无函数包裹时，配合小驱动表才可能通过分区裁剪提升性能。

MySQL 8.0+ 的 PARTITION BY 对 JOIN 有加速作用吗？

没有直接加速。分区表本身不改变 JOIN 的执行逻辑，MySQL 的查询优化器在大多数 JOIN 场景下仍会扫描全部分区（除非 WHERE 条件能精确裁剪到单个或少数分区）。真正起效的是「分区裁剪 + 联合索引 + 小范围驱动表」这个组合。常见错误是建了 RANGE 分区却用 user_id 做 JOIN 键——分区字段和 JOIN 字段不一致，裁剪完全失效。

• 确保 JOIN 条件中至少有一侧的字段与分区键相同（例如都按 created_at 分区，且 ON 子句含 t1.created_at = t2.created_at）
• 分区字段必须有对应索引，否则即使能裁剪，也因全表扫描分区内部而失去意义
• 避免在分区键上使用函数，如 DATE(created_at)，会导致裁剪失效

PostgreSQL 中如何让 HASH JOIN 实际并行起来？

得同时满足三个条件：并行计划被选中、工作进程数足够、JOIN 一侧足够大。默认情况下，PostgreSQL 只对“大表驱动小表”且小表可广播时才启用并行 HASH JOIN；如果两边都大，它可能退回到串行 MERGE JOIN 或更慢的 NESTED LOOP。

• 检查执行计划是否出现 Workers Launched: N 和 Parallel Hash 字样，没出现就说明没并行
• 设置 max_parallel_workers_per_gather ≥ 2（默认常为 0 或 2），且 parallel_setup_cost 和 parallel_tuple_cost 别设太高
• 小表（被广播的一侧）必须小于 work_mem × 并发数，否则降级为串行；可通过 SET work_mem = '256MB' 临时调高

ClickHouse 的 JOIN 为什么有时比本地 GROUP BY 还慢？

因为 ClickHouse 默认把 JOIN 当作「左表流式读取 + 右表全量加载进内存」来处理。一旦右表超过内存阈值（由 max_bytes_in_join 控制），就会报错 Memory limit (for query) exceeded 或自动退化成低效的 ANY LEFT JOIN + 外部临时表落盘。

• 优先用 IN 替代 JOIN：比如 WHERE user_id IN (SELECT user_id FROM dim_users WHERE is_vip)，它走向量化 IN 查询，不加载整张维表
• 必须用 JOIN 时，确保右表已用 ReplacingMergeTree 或 CollapsingMergeTree 压缩，并设置 join_algorithm = 'partial_merge'（适用于右表超大但 key 有序场景）
• 避免 USING 字段类型不一致，比如左表是 UInt32、右表是 Int64，会强制 cast 导致无法利用索引

Spark SQL 中 BROADCAST JOIN 触发失败的典型表现

作业卡在 Stage 0，Driver 日志反复打印 Size estimator for relation ... returned size > broadcast threshold，最终 fallback 成 SHUFFLE_HASH_JOIN 或 SHUFFLE_MERGE_JOIN，Shuffle 数据暴增。根本原因不是表“大”，而是 Spark 估算错了右表大小——尤其当表来自 Parquet 文件且未写入统计信息时。

• 手动触发统计信息收集：ANALYZE TABLE dim_user COMPUTE STATISTICS（Hive 兼容模式）或 spark.sql("ANALYZE TABLE dim_user COMPUTE STATISTICS FOR ALL COLUMNS")
• 临时强制广播：SELECT /<em>+ BROADCAST(t2) </em>/ * FROM fact t1 JOIN dim_user t2 ON t1.uid = t2.uid，但需确认 t2 实际大小 ≤ spark.sql.autoBroadcastJoinThreshold（默认 10MB）
• 若右表是动态生成的 DataFrame，调用 .hint("broadcast") 比 SQL hint 更可靠，避免 plan 重用导致误判

分区裁剪是否生效、并行 Worker 是否真正参与、广播阈值是否被误估——这些都不是看语法对不对，而是得盯住执行计划里的实际行为。查不到 Actual Rows 或 Workers Launched，光改 SQL 没用。