在 SQL Server 中，WHERE 子句在逻辑上先于 TOP 执行。至于扫描是否在找到 10 行后就停止，答案是：通常会提前终止，但具体行为取决于执行计划中是否存在 ORDER BY 等“阻塞”操作符。

🎯 逻辑顺序：WHERE 先行，TOP 收尾

SQL 语句的书写顺序与逻辑处理顺序并不一致。SQL Server 遵循一个固定的逻辑查询处理阶段，关键部分的顺序如下：

1. FROM / JOIN：确定数据源。

2. WHERE：对数据源进行过滤，剔除不满足条件的行。

3. GROUP BY / HAVING：进行分组和组级过滤。

4. SELECT：选择输出列。

5. DISTINCT：去除重复行。

6. ORDER BY：对结果集进行排序。

7. TOP：从最终排序好的结果集中，选取指定数量的行。

因此，SELECT TOP 10 * FROM Student WHERE age > 20 的逻辑是：先通过 WHERE 筛选出所有年龄大于 20 的学生，然后（通常是在排序后）再从中取出前 10 条记录。TOP 不会改变 WHERE 的筛选范围。

⚙️ 物理执行：“足够即停”与“提前终止”

逻辑顺序是固定的，但物理执行引擎为了优化性能，会根据执行计划采用提前终止（Early Termination）机制。

核心规则是：TOP 操作符一旦从其子操作符（如扫描、查找）那里接收到了足够数量的行（本例中是 10 行），它就会停止向子操作符请求更多数据，并向其发出“可以关闭”的信号。

但这会带来一个关键区别，取决于查询中是否有 ORDER BY：

场景一：没有 ORDER BY（最常见也最高效）

SELECT TOP 10 * FROM Student WHERE age > 20;

在这种情况下，只要扫描操作符找到前 10 条满足 WHERE age > 20 条件的行，它就会立刻停止扫描，并返回这 10 行。表剩余的部分完全不会被扫描，效率极高。

但需要注意，由于没有 ORDER BY，返回的这 10 行是不确定的（undefined），SQL Server 不保证每次运行都返回相同的 10 行。

场景二：有 ORDER BY（可能产生“阻塞”）

SELECT TOP 10 * FROM Student WHERE age > 20 ORDER BY name;

这里存在一个潜在的性能陷阱。为了确保 name 的顺序，执行计划中通常会有一个 SORT（排序） 操作符。SORT 是一个阻塞操作符：在它输出第一行之前，必须“看见”所有满足 WHERE 条件的行，以完成全局排序。

因此，在这种情况下，尽管 TOP 最终只需要 10 行，但WHERE 条件所涉及的扫描可能仍然需要处理所有匹配的行，因为 SORT 需要它们全部就位。只有当 ORDER BY 的列上存在合适的索引，使得数据可以按顺序直接读取（而无需显式排序）时，才可能实现真正的“提前终止”。

💎 总结