FORCESCAN不能用于JOIN的ON条件，仅能作用于FROM或JOIN子句中单张表的别名后，强制全表扫描但不改变连接算法；滥用会导致性能恶化，真正需用场景极少。
FORCESCAN 不能用在 JOIN 的 ON 条件上
FORCESCAN 是表级提示，只作用于单个表的访问方式，不是连接算法控制手段。它不会改变 JOIN 类型（如 LOOP / HASH / MERGE），也不会影响优化器对驱动表或连接顺序的判断。试图在 INNER JOIN t1 ON ... 中对 t1 加 WITH (FORCESCAN)，只会强制 t1 全表扫描，但若 t1 是被驱动表，这反而让每次匹配都扫全表，性能更差。
常见错误现象：Actual Rows 暴涨、执行计划里出现重复的 Clustered Index Scan 节点、逻辑读飙升。
- FORCESCAN 只能用于 FROM 或 JOIN 子句中某张表的别名后，语法为
FROM t WITH (FORCESCAN)或JOIN t WITH (FORCESCAN) ON ... - 它不解决“该不该走索引”，而是绕过索引直接扫——适用于极低选择性列（如
status IN (0,1)）且统计信息严重失真时 - 在 JOIN 场景下，除非你明确知道这张表无论如何都该被全扫（比如它是维度表且仅几十行），否则不要加
JOIN 性能差时，优先检查驱动表和索引
90% 的慢 JOIN 不是因为没扫对表，而是驱动表选错 + JOIN 列没索引。FORCESCAN 对这类问题完全无效，甚至掩盖真实瓶颈。
实操建议：
- 用
SET STATISTICS XML ON查看执行计划，盯住EstimatedRows和ActualRows差距最大的那个 JOIN 输入节点——那张表大概率是被误当驱动表的大表 - 确认所有 JOIN 列类型严格一致（
INTvsVARCHAR隐式转换会废掉索引） - 在被驱动表的 JOIN 列上建索引，例如
orders.user_id上建INDEX IX_orders_user_id ON orders(user_id) - 把 WHERE 过滤条件尽量前移到 ON 子句或子查询里，缩小中间结果集，比强行扫某张表更有效
真正需要 FORCESCAN 的 JOIN 场景极少
它只在一种组合下有点用：小维度表 + 极低基数列 + 统计信息失效 + 优化器死活不肯扫表（比如误判索引查找更快）。但这种场景本身说明数据分布或统计已异常，应先修复根本问题。
示例（仅作说明，不推荐日常使用）：
SELECT u.name, o.order_date FROM users u INNER JOIN orders o WITH (FORCESCAN) ON u.id = o.user_id WHERE u.is_active = 1;
这里加 FORCESCAN 的前提是：orders 表只有几百行，user_id 列几乎全非空、无区分度，且优化器因旧统计信息坚持走 IX_orders_user_id 导致大量无效索引查找。但更合理的做法是更新统计：UPDATE STATISTICS orders WITH FULLSCAN。
容易踩的坑：
- 在大事实表上加
FORCESCAN，等于主动放弃所有索引，IO 直接翻倍 - 与
INDEX提示混用（如WITH (FORCESCAN, INDEX(IX_x))）会报错，二者互斥 - 在视图或 CTE 中加 FORCESCAN，提示可能不生效，因为优化器重写阶段会丢弃
替代 FORCESCAN 的更安全手段
想控制 JOIN 行为，有比 FORCESCAN 更可控、副作用更小的方式：
- 用
OPTION (HASH JOIN)或OPTION (MERGE JOIN)显式指定连接算法，尤其当两张表都很大且已有排序/聚集时 - 用
OPTION (FORCE ORDER)固定连接顺序——但仅限验证阶段，上线前必须配合UPDATE STATISTICS - 对 JOIN 列建覆盖索引，比如
INDEX IX_orders_user_id_inc ON orders(user_id) INCLUDE (order_date)，避免回表同时提升查找效率 - 在存储过程中，用临时表预过滤再 JOIN：
SELECT * INTO #filtered_orders FROM orders WHERE created_at > @date，然后在#filtered_orders上建索引
FORCESCAN 是个窄口子工具，用错地方比不用还危险。它不解决 JOIN 逻辑问题，只干预物理访问路径；而绝大多数 JOIN 性能问题，出在逻辑设计层——表顺序、索引结构、条件位置。
