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 没用。
