表之间连接顺序的优化，是 SQL 调优里一个蛮关键的点。驱动表选得好，性能差距能直接上个数量级。简单说，就是先能过滤最多数据的表，减少后续表的量。Oracle 执行计划里，这种思路体现得。尤其在多表连接的场景，能不能提前缩小row source，直接决定了你 SQL 跑得顺不顺。
执行计划里的row source顺序，其实不是你写 SQL 时表的顺序，而是 Oracle 根据成本估算自动决定的。你写在前的不一定先执行，所以别太迷信写法。可以用EXPLAIN PLAN或者AUTO TRACE看真实顺序，配合着看每一步的访问方法，像是TABLE ACCESS FULL、NESTED LOOPS、HASH JOIN这些，判断是不是走了你预期的路径。
有时候执行计划看起来怪怪的？嗯，别急着改 SQL，先看看WHERE 子句有没有写清楚，索引是不是生效了。如果你的过滤条件放错表了，就容易导致大表先跑，小表白搭，效率自然低。反过来，小表先跑，大表配合走索引，那性能可就上来了。
想更深入搞懂这些，可以看看下面几个资料，讲得都还不错：
如果你经常写多表连接的 SQL，建议多观察执行顺序和访问方式，慢 SQL 多时候就是这俩没搞明白。