分区字段未对齐导致剪枝失效是亿级表JOIN变慢主因；需两表同维分区且JOIN条件显式对齐，类型、值域、命名均须一致；隐式转换和大小写敏感亦会断链。
分区字段没对齐，JOIN再快也白搭
分区剪枝失效是亿级表JOIN变慢的头号原因。不是加了分区就自动剪枝，关键是JOIN条件里必须显式包含分区字段，且两边字段类型、值域、命名逻辑要能对齐。
- 常见错误：
SELECT * FROM sales PARTITION(p2024) JOIN users ON sales.user_id = users.id—— 这里sales用了分区限定，但users没按region或dt分区，导致sales的分区剪枝无法传导，引擎仍可能扫描全量users - 正确做法：两表都按相同维度（如
dt）分区，并在JOIN条件中带上AND sales.dt = users.dt，让优化器识别出可同时裁剪 - 注意：Hive/Spark中
dt STRING和dt DATE不等价，隐式转换会断掉剪枝链；Trino里分区字段名必须完全一致，大小写敏感
并行度设太高反而拖垮集群
并行计算不是越多越快，尤其当JOIN涉及大宽表或数据倾斜时，盲目调高并发只会加剧Shuffle压力和内存OOM。
- Spark场景下，
spark.sql.adaptive.enabled=true比硬调spark.sql.adaptive.coalescePartitions.enabled更稳妥，它能在运行时动态合并小任务，避免“1000个5MB的shuffle文件”这种反模式 - ClickHouse用
distributed_product_mode = 'local'时，若JOIN跨分片，实际执行仍走本地+远程两层，此时max_threads应设为CPU核心数×1.5，而非×4 - MySQL 8.0+的哈希JOIN默认禁用并行，需显式开
SET SESSION optimizer_switch='hash_join=on';，但只对JOIN ... ON a.x = b.x有效，ON a.x > b.y这类范围条件会退化回BNL
小表广播失败的三个隐蔽信号
你以为BROADCAST提示生效了，其实可能早被优化器悄悄忽略——尤其当统计信息不准或小表实际膨胀时。
- 现象1：执行计划里出现
Exchange (REPARTITION)而不是BroadcastExchange，说明广播被拒；查EXPLAIN EXTENDED看是否报Size of relation is larger than autoBroadcastJoinThreshold - 现象2：Spark UI里Task数量远超预期，且大量Task耗时集中在Shuffle Read，大概率是小表没播成，被迫走SortMergeJoin
- 现象3：Hive中
/*+ MAPJOIN(t) */注释写了，但t表含NULL分区或LOCATION指向HDFS非根路径，Hive 3.1+会直接跳过广播优化
JOIN后COUNT(*)卡住？先看谓词下推有没有漏
亿级JOIN结果集本身不大，但中间过程爆炸，根本原因是过滤条件没下推到JOIN前，导致先做全量关联再过滤。
- 典型陷阱：
SELECT COUNT(*) FROM big_log l JOIN dim_user u ON l.uid = u.id WHERE u.status = 'active'—— 若dim_user未按status分区，这个WHERE会被拖到JOIN之后执行 - 修复方式：把过滤提前，改写为
SELECT COUNT(*) FROM big_log l JOIN (SELECT id FROM dim_user WHERE status = 'active') u ON l.uid = u.id，强制下推 - Trino中还可加
/*+ pushdown_filters */提示，但仅对Connector支持谓词下推的场景有效（如Delta Lake、Iceberg），MySQL Connector不支持
真正卡住性能的，往往不是JOIN本身，而是分区字段语义不一致、统计信息陈旧、或自以为“小”的表在运行时因NULL值或数据漂移突然膨胀几倍——这些点不手动验证，光调参数没用。
