小表驱动大表能压低内存占用，因SQL Server嵌套循环连接中，小表作外循环可大幅减少内表扫描次数、中间结果及哈希/排序开销，避免tempdb溢出和内存激增。
嵌套查询本身不直接“占内存”，但 IN、EXISTS 或多层子查询常导致 SQL Server 生成低效执行计划，引发大量中间结果缓存、重复扫描和内存中临时结构膨胀——尤其当小表未驱动大表时，内存压力会陡增。
为什么小表驱动大表能压低内存占用
SQL Server 的嵌套循环（Nested Loops）连接在小表作为外循环（Outer Table）时，每行只触发一次内表（大表）的索引查找或范围扫描；若反过来，大表作外循环，就会对小表反复查 thousands/millions 次，产生海量中间行、哈希构建开销或排序溢出到 tempdb（间接吃内存）。
典型错误现象包括：
-
SELECT * FROM Orders WHERE CustomerID IN (SELECT CustomerID FROM Customers WHERE City = 'NYC')—— 若Customers表很小（万级），Orders很大（千万级），但优化器没选对驱动顺序，可能把Orders当外循环，逐行去查Customers - 执行计划中出现
Table Spool (Eager Spool)或Sort节点，且 I/O 和内存估算值远高于实际数据量 -
sys.dm_exec_query_memory_grants显示该查询申请了异常高的 grant（如 >512 MB），但返回行数很少
强制小表驱动的实操手段
不能只靠加索引，得让优化器“看懂”你的意图。以下方法按优先级排列：
- 用
INNER JOIN显式重写，而非IN/EXISTS：SELECT o.* FROM Orders o INNER JOIN Customers c ON o.CustomerID = c.CustomerID WHERE c.City = 'NYC'—— 这样优化器更容易基于统计信息选择Customers为驱动表 - 给小表的筛选列建覆盖索引，让其成为“轻量级驱动源”：
CREATE INDEX IX_Customers_City_CustomerID ON Customers (City) INCLUDE (CustomerID)—— 索引够小、可 Seek、无 Key Lookup，驱动成本极低 - 必要时加
OPTION (FORCE ORDER)（慎用）： 仅当执行计划明确错判驱动顺序且无法通过统计信息修正时使用，例如... FROM Customers c INNER JOIN Orders o ... OPTION (FORCE ORDER) - 更新小表统计信息：
UPDATE STATISTICS Customers WITH FULLSCAN, NORECOMPUTE—— 小表行数少，全扫快，且防止优化器误判其基数
索引设计必须匹配驱动逻辑
光有索引不够，索引结构得服务于“小表快速输出驱动键”这个目标：
- 驱动小表的 WHERE 条件列必须是索引首列（如
City），否则无法高效 Seek - JOIN 列（如
CustomerID）必须包含在索引中（INCLUDE或联合索引第二列），避免回表放大内存压力 - 避免在小表上建宽索引（比如
INCLUDE十几个列）—— 索引本身变大，缓存效率下降，反而增加 buffer pool 占用 - 哈希索引（内存优化表）不适用此场景：它不支持范围查询（
City = 'NYC'可以，但City LIKE 'N%'不行），且无法驱动 Nested Loops
容易被忽略的内存陷阱
即使驱动顺序正确，以下细节仍会导致内存意外飙升：
-
SELECT *从大表中拉全字段：哪怕只返回 100 行，若大表单行宽 2KB，就需 200KB 内存暂存；改用明确列列表，减少 buffer 和网络序列化开销 - 小表被隐式转换：如
Customers.City是varchar(50)，但查询里写成WHERE City = N'NYC'（Unicode 字符串），触发全表扫描+内存排序 - 嵌套层级超过 2 层后，优化器可能放弃 Nested Loops 改走 Hash Join，而 Hash 构建阶段会申请大内存 grant，且不可复用
- 内存优化表（In-Memory OLTP）上不能用
OPTION (FORCE ORDER)，也不支持所有 JOIN 提示，驱动逻辑需靠索引结构和本机编译过程硬编码
