SSMS 2018基于ROW_NUMBER分区筛选含Sent/Resent状态的Type数据

原实现存在两个核心缺陷：

• 筛选粒度错位：仅以Code作为匹配维度，没有将Type纳入判断范围，导致同一个Code下哪怕某个Type不满足双Status要求，也会因为同Code下另一个Type符合条件被错误带出（也就是你遇到的Kim的Sheet记录被误保留的问题）
• 筛选逻辑不可靠：用row_num=2作为判断标识本身没有语义支撑，row_num是窗口排序生成的序号，无法直接等价于“该分组同时存在Sent和Resent两种状态”；同时原CTE仅做了全表透传，没有做任何聚合计算，等同于直接查原表，没有实际筛选作用

按照需求定义，判断的最小单元是「同一个Code下的同一个Type」，需要满足两个硬性条件：该单元下至少1条Status='Sent'、至少1条Status='Resent'，匹配逻辑分两步：

1. 先聚合筛选出所有符合双Status要求的Code+Type组合
2. 用这些合法组合关联原表，返回对应组合下的所有记录

WITH ValidTypeGroup AS (
    -- 按Code+Type粒度筛选满足双Status要求的组合
    SELECT 
        Code,
        Type
    FROM #MyTable
    GROUP BY Code, Type
    HAVING
        -- 校验存在Sent状态记录
        MAX(CASE WHEN Status = 'Sent' THEN 1 ELSE 0 END) = 1
        -- 校验存在Resent状态记录
        AND MAX(CASE WHEN Status = 'Resent' THEN 1 ELSE 0 END) = 1
)
SELECT t.*
FROM #MyTable t
-- 关联时必须同时匹配Code和Type，避免跨Type误筛
INNER JOIN ValidTypeGroup v
    ON t.Code = v.Code
    AND t.Type = v.Type

对照你提供的样例数据：

• Code123/Type=Sheet分组：无Resent记录，全量剔除
• Code221/Type=Sheet分组：无Resent记录，全量剔除
• Code221/Type=Book分组：同时覆盖Resent、Sent状态，全量保留

不推荐沿用row_num做判断：如果保留用row_num做判断的思路，哪怕把匹配粒度从Code调整为Code+Type，只要窗口排序规则变动（比如Status字段的排序优先级变化、存在其他中间状态值），row_num的数值就会失去对应语义，很容易出现误判。直接基于Status字段做存在性校验的逻辑不受窗口函数排序规则影响，稳定性更高。

内容的提问来源于stack exchange，提问作者Red