重构他人SQL代码：MAX(Date)与MAX(Locator)关联是否冗余？

我正在重构一位已离职人员编写的SQL代码。该查询选取MAX(T.USERDATE2)作为BillPayDate，却通过子查询获取的MAX(Locator)关联同一张TRACKING表。Locator是记录创建时分配的任意连续编号，理论上MAX(Locator)与MAX(USERDATE2)均可获取最新记录，请问这种看似冗余的写法是否存在合理用途？

相关SQL代码如下：

SELECT DISTINCT
    MAX(T.USERDATE2) AS BillPayDate
INTO
    #PersonBillPayAccounts
FROM 
    [TRACKING] T
JOIN
    (SELECT ACCOUNT_NUMBER, MAX(Locator) AS Locator
     FROM [TRACKING]
     WHERE Type = 32
       AND (userdate2 IS NOT NULL OR userdate2 != '') 
     GROUP BY ACCOUNT_NUMBER) L ON T.ACCOUNT_NUMBER = L.ACCOUNT_NUMBER 
                                AND T.LOCATOR = L.Locator 
                                AND T.Type = 32

这种写法并非完全冗余，存在以下合理场景：

• 规避日期字段的人为篡改：虽然理论上USERDATE2对应最新记录的日期，但实际业务中可能存在人为修改旧记录日期的情况。而Locator是记录创建时生成的连续编号，不会被后续修改，用MAX(Locator)能确保拿到真正的最新创建记录，再取该记录的USERDATE2才是准确的最新日期。
• 处理日期重复的歧义：如果多个记录的USERDATE2完全相同，直接用MAX(USERDATE2)只能得到日期值，无法确定对应的具体记录。而Locator是唯一的，MAX(Locator)能精准定位到最新创建的那一条，避免因日期重复导致的数据不确定性。
• 适配历史业务逻辑：子查询里特意加了(userdate2 IS NOT NULL OR userdate2 != '')的条件，说明历史上可能存在USERDATE2为空或无效的情况，当时用Locator作为唯一标识取最新记录是更可靠的方案。后来即使日期字段数据正常了，代码也没做修改，保留了原有的可靠逻辑。
• 性能优化的考量：如果Locator是主键或建有索引，MAX(Locator)的查询效率会远高于MAX(USERDATE2)（尤其是当USERDATE2没有索引时）。通过子查询先过滤出每个账户的最新Locator再关联，比直接按日期分组查询的性能更好。

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