MySQL中“小表驱动大表”指让过滤后结果集更小的表作驱动表以减少嵌套循环次数，LEFT JOIN强制左表驱动需靠WHERE提前过滤，INNER JOIN可由优化器重排，索引、EXPLAIN验证和统计信息更新是关键保障。
小表必须驱动大表，但具体怎么驱动、在哪驱动、用什么驱动，得看数据库类型和 JOIN 类型——不是所有场景都能靠“小表放左边”解决。
MySQL 中 LEFT JOIN 强制左表为驱动表，没法换顺序
写 big_table LEFT JOIN small_table ON ...，哪怕 small_table 只有 100 行，big_table 也会被全扫。EXPLAIN 里一定看到左表 type=ALL，右表 type=ref，但响应慢得离谱。
- ON 条件不触发过滤，只有
WHERE才能缩小驱动表数据集 - 如果业务允许，改写成
INNER JOIN，让优化器有机会重排驱动表 - 实在要用 LEFT JOIN，就在
WHERE里提前过滤左表，比如WHERE big_table.status = 'active'，比靠 JOIN 条件更有效 - 别依赖
STRAIGHT_JOIN强制顺序——它禁用优化器重排，容易在统计信息更新后翻车
Spark SQL 用 BROADCAST 强制小表广播，别等自动触发
默认 spark.sql.autoBroadcastJoinThreshold 是 10MB，但很多维表（比如用户画像表）实际 30MB、50MB，仍属于“逻辑小表”，手动广播更稳。
- 显式调用
broadcast(small_table)比依赖阈值更可控 - SQL 里用 hint：
SELECT /*+ BROADCAST(small_table) */ ...，注意表名要跟 FROM 中的别名一致 - 广播前确认小表真实大小：用
df.count()和df.explain()看是否真进 Broadcast Hash Join 阶段 - 如果小表带分区字段，先
repartition(100, "join_key")再广播，避免 driver 端单点内存压力
Hive 的 MAPJOIN 不是开关一开就生效，得看 size 和 hint
Hive 默认不启用 MAPJOIN，即使小表满足条件（≤2 万行、≤25MB），没 hint 也走普通 Reduce Join。
- 必须加
/*+ mapjoin(small_table) */，且括号里是表名或别名，不是字段名 - 小表不能有 WHERE 过滤——MAPJOIN 要求小表完整加载进 mapper 内存，子查询里的过滤会被忽略
- 检查日志里是否有
MapJoinOperator，而不是ReduceSinkOperator，才能确认生效 - 如果小表略超阈值（比如 30MB），可临时调大
hive.mapjoin.smalltable.filesize，但别超过单个 mapper 内存上限
PostgreSQL 不选驱动表，但会乱选 JOIN 顺序
PG 没有“驱动表”概念，它枚举所有可能顺序选成本最低的——但这个“成本”严重依赖 ANALYZE 结果。没跑过 ANALYZE 或数据突增后未刷新，它可能把小表当被驱动对象反复扫描。
- 查执行计划用
EXPLAIN (ANALYZE, BUFFERS)，重点看Actual Rows和Rows Removed by Filter - 多维表 JOIN 事实表时（比如 6 张百行维表），设
SET join_collapse_limit = 1关闭重排，自己控制顺序 - 对小表建部分索引（如
CREATE INDEX idx_user_active ON users (id) WHERE status = 'active'），能让统计更准 - 函数索引会让
pg_stats.n_distinct失真，用SELECT * FROM pg_stats WHERE tablename = 'xxx'核对是否合理
真正卡住性能的，往往不是“该不该广播”或“索引建没建”，而是 JOIN 前没做数据裁剪、LEFT JOIN 被当成 INNER JOIN 用、或者小表其实早被 WHERE 过滤到只剩几行——但优化器没感知到。这些细节不查执行计划根本看不到。
