mysql中驱动表应为小表且位于left join左侧或inner join左端，因驱动表全扫描而被驱动表走索引；但left join语法强制左表为驱动表，无法优化重排，需通过改写为inner join或where提前过滤来优化。

JOIN时MySQL怎么选驱动表

MySQL的JOIN不是对称操作，驱动表（左表）会被全扫描，被驱动表（右表）走索引查找。所以小表做驱动表、大表放右边，才能减少嵌套循环次数。但注意：这仅适用于NESTED LOOP JOIN（MySQL 8.0.18前默认），如果启用了hash_join=on（8.0.19+），小表未必必须放左边——但别依赖它，默认仍按传统规则设计。

• 用EXPLAIN看type列：驱动表通常是ALL或index，被驱动表最好是ref/eq_ref
• 显式指定驱动顺序？不行。MySQL不支持STRAIGHT_JOIN以外的强制方式，而STRAIGHT_JOIN只在SELECT开头生效，且会禁用优化器重排，慎用
• 多表JOIN时，优化器按统计信息估算成本，但小表数量一多（比如5个100行的表JOIN一个千万行表），它可能误判——此时手动把最小的2–3个表先JOIN成临时结果集，再连大表更稳

LEFT JOIN里NULL值怎么影响驱动表选择

LEFT JOIN的左表一定是驱动表，无论大小。这是语法决定的，优化器不能调换顺序。如果你写big_table LEFT JOIN small_table ON ...，MySQL会全扫big_table，哪怕small_table有完美索引也没用。

• 现象：EXPLAIN显示左表type=ALL，右表type=ref，但响应慢得离谱
• 解法：如果业务逻辑允许，把查询改写为INNER JOIN，让优化器有机会重排；否则，提前过滤左表——加WHERE条件缩小驱动集，比靠JOIN条件更有效
• 注意：ON里的条件不会过滤驱动表，只有WHERE才会。比如LEFT JOIN t2 ON t1.id = t2.id WHERE t2.status = 'ok'，实际变成INNER JOIN语义，但写法上仍强制t1驱动——这时不如直接写INNER JOIN

PostgreSQL的JOIN顺序为什么不能靠猜

PostgreSQL没有“驱动表”概念，它用动态规划或遗传算法枚举所有JOIN顺序，选成本最低的。所以你写A JOIN B JOIN C，执行计划里可能是B → A → C。但它依赖准确的统计信息——如果ANALYZE没跑过，或者表数据突变后未更新统计，它可能选错顺序，导致小表被反复扫描。

• 查执行计划用EXPLAIN (ANALYZE, BUFFERS)，重点看Actual Rows和Rows Removed by Filter
• 小表太多时（如6个百行维表JOIN事实表），PG可能因搜索空间爆炸退化为贪心算法，结果次优。此时用SET join_collapse_limit = 1强制不重排，自己控制顺序
• 函数索引、部分索引会影响统计准确性，pg_stats里查n_distinct是否合理，不合理的要手动ANALYZE table_name (col)

SQL Server中FORCE ORDER到底动了什么

OPTION (FORCE ORDER)会让SQL Server完全忽略代价估算，严格按FROM子句从左到右执行JOIN。它不改变物理操作类型（比如还是用HASH MATCH），但锁定了连接顺序——这对小表驱动大表的场景是双刃剑：可控，但容易把本可下推的过滤条件卡在后面。

• 典型坑：SELECT * FROM small1 s1 JOIN big b ON s1.id = b.s1_id JOIN small2 s2 ON b.id = s2.bid OPTION (FORCE ORDER)，如果small2有WHERE s2.type = 'X'，这个条件无法提前过滤big，只能等JOIN完再筛
• 替代方案：用CTE预先过滤小表，再JOIN大表，比FORCE ORDER更安全
• 启用后务必看SET STATISTICS XML ON输出的EstimatedRows和ActualRows是否接近，差距大说明统计失效，该更新UPDATE STATISTICS了

驱动表选择看着是顺序问题，实际牵扯统计信息质量、JOIN算法切换、甚至查询重写能力。最危险的不是选错，而是以为“小表放左就万事大吉”，却没验证执行计划里真实的数据流动路径。