SQL 优化实战：驱动表选择与 Hash 关联

在复杂 SQL 查询的优化中，表连接方式的选择直接决定了执行效率。本文通过一个实际案例，解析驱动表优化与 Hash 关联在多表连接场景中的应用差异，揭示如何根据数据特征选择最优策略。

一、案例背景：一条慢查询的困境

某业务 SQL 涉及多表连接，包含CT_ACT、CT_ACT_STAGE、CT_ACT_STAGE_PRODUCT、CT_STORE_PRODUCT_REL四张表，核心逻辑是通过活动 ID 关联商品与门店关系，查询耗时达 11.25 秒。其执行计划显示：

• 采用嵌套循环连接（NESTED-LOOP JOIN） 作为连接方式；
• 表ASP（CT_ACT_STAGE_PRODUCT）、t（CT_STORE_PRODUCT_REL）等通过索引扫描过滤数据，但整体成本较高（总 COST=565）；
• 多次嵌套循环导致内层表扫描次数累积，成为性能瓶颈。

二、核心分析：嵌套循环的 “驱动表依赖”

嵌套循环连接的性能高度依赖驱动表的选择：外层表（驱动表）的扫描结果会作为内层表的输入条件，若驱动表返回行数过多，内层表的扫描次数将呈指数级增长。

在本案例中，执行计划默认以ASP表为驱动表，但该表数据量较大（table_rows=9737755），即使通过索引过滤后返回 1 行，后续嵌套循环仍需多次扫描其他表。此外，t表数据量达 656 万行，嵌套循环下的逐行匹配进一步加剧了耗时。

三、优化路径：驱动表调整 vs Hash 关联切换

针对嵌套循环的局限性，可从两个方向优化：

1. 驱动表优化：选择小表作为外层

驱动表的核心原则是 **“小表驱动大表”**—— 优先扫描返回行数少的表，减少内层循环次数。

• 分析各表过滤后的数据量：CAS表（CT_ACT_STAGE）仅 11 万行，且通过ACT_ID关联后返回行数极少，适合作为驱动表；
• 调整连接顺序：让CAS表作为外层，依次关联ASP、t、A表，减少内层表的扫描次数。

优化后，嵌套循环的内层扫描次数从 “大表行数 ×N” 降至 “小表行数 ×N”，理论上可减少大量 IO 操作。

2. Hash 关联：大数据集的高效连接

当表数据量较大（如本例中ASP和t表均超百万行），嵌套循环的逐行匹配效率低下，此时Hash 关联更具优势：

• 原理：先对驱动表数据构建哈希表（内存中），再扫描被驱动表并通过哈希函数快速匹配，避免逐行比较；
• 适用场景：非索引连接、大表连接（行数超 10 万）、等值连接（JOIN ON条件为=）。

在本案例中，若ASP与t表的PRODUCT_ID关联无高效索引，可强制使用 Hash 关联（通过USE_HASHhint），将多次嵌套循环转为一次哈希表构建 + 一次全表扫描，大幅降低关联耗时。

四、执行计划对比与适用场景

优化方式	核心逻辑	优势场景	局限性
驱动表优化	小表驱动大表，减少循环次数	有索引的小表连接、非等值连接	大表驱动时效率骤降
Hash 关联	哈希表快速匹配	大表等值连接、无索引连接	消耗内存、不支持非等值连接

在本案例中，若表间存在有效索引，优先通过调整驱动表顺序优化嵌套循环；若索引缺失或数据量过大，切换为 Hash 关联更能提升性能。

五、总结：连接策略的选择准则

1. 优先评估数据量：小表（<1 万行）用嵌套循环 + 驱动表优化，大表用 Hash 关联；
2. 依赖索引情况：有高效索引时嵌套循环更优，无索引时 Hash 关联更可靠；
3. 连接类型：等值连接优先 Hash 关联，非等值连接（>、<、LIKE）只能用嵌套循环 + 驱动表优化。

通过合理选择连接方式与驱动表，本例中的 11.25 秒查询可优化至秒级甚至毫秒级，印证了 “细节决定性能” 的 SQL 优化之道。