看起来你已经做了相当细致的排查，能精准定位到TABLE_C是性能骤降的核心，还通过OPTION(FORCE ORDER)把查询速度从33秒拉到了2秒，这已经是个很棒的突破了！我结合你的场景和尝试过的方案，再梳理几个更深入的优化方向，以及为什么会出现这种情况：

先搞懂为什么FORCE ORDER能解决问题 #

你的原查询连接顺序是TABLE_SUB → TABLE_R → TABLE_C，但SQL Server优化器可能自己选了更差的连接顺序（比如先把100万行的TABLE_R和66k行的TABLE_C关联，生成百万级的中间结果，再和23k行的TABLE_SUB过滤），这直接导致了IO爆炸。FORCE ORDER强制优化器严格按照你写的顺序执行：先从最小的数据集TABLE_SUB（23k行）出发，关联TABLE_R得到对应23k行左右的结果，最后再关联TABLE_C，中间数据量始终很小，所以速度骤降。

这个选项可以长期保留，是快速解决问题的方案，但我们也可以做一些优化让优化器自己选对顺序，避免依赖强制选项。

针对性的索引优化 #

虽然你已经加了MasterID的索引，但可以给TABLE_C创建一个覆盖索引，让查询完全不需要回表（哪怕聚集索引包含所有列，窄索引的扫描/查找IO成本更低）：

CREATE NONCLUSTERED INDEX IX_Table_C_MasterID_Incl_Name 
ON dbo.Table_C (MasterID)
INCLUDE (MasterName); -- 只包含查询需要的列，缩小索引体积

TABLE_C只有66k行，这个索引不会占用太多空间，但能让关联时的索引查找效率更高，避免出现不必要的扫描。

让统计信息更精准 #

你已经执行了UPDATE STATISTICS，但默认的抽样统计可能对数据分布不均匀的表不够准确。试试用全扫描更新统计，让优化器拿到最真实的数据分布：

UPDATE STATISTICS dbo.Table_C WITH FULLSCAN;
UPDATE STATISTICS dbo.TABLE_R WITH FULLSCAN;
UPDATE STATISTICS dbo.TABLE_SUB WITH FULLSCAN;

全扫描会遍历整张表生成统计信息，虽然耗时一点，但能让优化器更准确地判断连接顺序和操作符选择，说不定之后不用FORCE ORDER也能跑很快。

优化查询逻辑，提前缩小数据集 #

你可以先把TABLE_SUB和TABLE_C的关联提前，只保留需要的MasterID和MasterName，再去关联TABLE_R，这样中间结果始终是小数据集：

WITH SubMasterNames AS (
    -- 先从TABLE_SUB获取唯一的MasterID，关联TABLE_C拿到名称
    SELECT DISTINCT TS.MasterID, C.MasterName
    FROM TABLE_SUB TS
    INNER JOIN TABLE_C C ON TS.MasterID = C.MasterID
)
SELECT 
    TS.MasterID, 
    TS.RecordNr, 
    TR.MasterName, 
    SMN.MasterName
FROM TABLE_SUB TS
INNER JOIN TABLE_R TR 
    ON TS.MasterID = TR.MasterID AND TS.RecordNr = TR.RecordNr
INNER JOIN SubMasterNames SMN 
    ON TS.MasterID = SMN.MasterID
OPTION (RECOMPILE); -- 让优化器根据CTE的实际数据量生成最优计划

这种写法会引导优化器优先处理小数据集，减少不必要的大表关联。

关于TABLE_R的额外说明 #

你提到SELECT * FROM TABLE_R要23秒，这说明TABLE_R的聚集索引扫描成本本身就不低（毕竟100万行，还有长字符串列）。不过你的查询只需要它的部分列，所以如果后续还有性能压力，可以给TABLE_R也创建覆盖索引，包含查询用到的列：

CREATE NONCLUSTERED INDEX IX_TABLE_R_MasterID_RecordNr_Incl_Cols
ON dbo.TABLE_R (MasterID, RecordNr)
INCLUDE (MasterName, Date1); -- 替换成你查询实际需要的列

这个索引和TABLE_R的聚集索引键一致，但只包含查询需要的列，体积会小很多，关联时的查找速度会更快。

总结 #

• 短期快速方案：保留OPTION(FORCE ORDER)，已经能稳定到2秒，足够满足需求；
• 长期优化：配合全扫描更新统计+覆盖索引，让优化器自主选择最优执行计划，减少对强制选项的依赖；
• 逻辑优化：提前关联小数据集，避免大表之间的无效关联。

内容来源于stack exchange