编写跨表校验Upload ID的脚本 过滤大文件上传超时误告警

核心判断逻辑 #

原有告警规则误报的核心原因是未区分「大文件本身上传耗时长」和「上传流程卡死」两种场景，优化后的校验链路严格对齐业务判断标准：

• 从Table A中拉取所有上传单的唯一Upload ID、创建时间字段，筛选出创建时间刚好达到「距当前时间10分钟」阈值的Upload ID集合
• 对筛选出的ID集合，检索Table B中、写入时间落在「当前时间往前10分钟区间」的所有条目，判断UploadFile列是否包含匹配的Upload ID
• 校验结果分支：
  • 若该Upload ID在Table B的对应时间区间内无任何匹配记录 → 判定为上传卡死，触发告警
  • 若存在匹配条目 → 说明文件已完成上传落库，流程正常结束，不触发告警

脚本开发常见踩坑点（即常规实现容易跑不通的核心原因） #

• 时间范围边界错配：不要把两个表的检索时间窗口混为一谈。Table A的筛选基准是「上传单创建时间满10分钟」，Table B的检索范围是「近10分钟产生的上传完成记录」，两个时间窗口都以当前系统时间为基准，不能错用Upload ID对应的创建时间当Table B的检索起点，否则会漏匹配跨时间窗口的完成记录
• 字符串匹配精度不足：Table B的UploadFile列是文件路径或文件名，直接用模糊匹配判断ID存在性很容易出现误判（比如ID为1212会错误匹配到ID为12123的文件记录）。需要根据实际文件命名规则，对UploadFile列做结构化解析提取Upload ID后再做精确匹配，不要直接用全字段模糊LIKE
• 重复告警未做隔离：如果每次脚本执行都全量扫描历史上传单，会对同一条卡死的上传流程反复触发告警。需要给Table A增加alert_mark字段，对已经触发过告警的ID做标记，后续执行时直接跳过，不重复处理

可直接复用的SQL查询逻辑 #

-- 筛选刚达到10分钟阈值、未告警过的待校验上传单
WITH pending_check_uploads AS (
    SELECT upload_id, create_time
    FROM table_a
    -- 覆盖定时任务1分钟的执行间隔，避免漏扫临界值的上传单
    WHERE create_time BETWEEN DATE_SUB(NOW(), INTERVAL 11 MINUTE) 
                        AND DATE_SUB(NOW(), INTERVAL 9 MINUTE)
      AND alert_mark = 0
),
-- 提取近10分钟Table B中已完成上传的ID集合
finished_uploads AS (
    SELECT DISTINCT
        -- 按实际文件命名规则解析提取Upload ID，示例规则为文件名中Upload ID以下划线分隔
        SUBSTRING_INDEX(SUBSTRING_INDEX(upload_file, '_', -1), '.', 1) AS matched_upload_id
    FROM table_b
    WHERE record_create_time BETWEEN DATE_SUB(NOW(), INTERVAL 10 MINUTE) AND NOW()
)
-- 输出无匹配完成记录的待告警ID
SELECT p.upload_id, p.create_time
FROM pending_check_uploads p
LEFT JOIN finished_uploads f 
ON p.upload_id = f.matched_upload_id
WHERE f.matched_upload_id IS NULL;

运行落地注意事项 #

• 定时执行频率建议设置为每1分钟一次，和上述时间窗口的覆盖范围匹配，避免漏过临界值的上传单
• 逻辑上线前需用历史存量数据做回溯校验，确认Upload ID的解析规则和实际文件命名完全匹配，避免出现「文件已上传完成却识别不到」的假阴性
• 对固定大文件（如10G以上的安装包、媒体资源）的上传场景，可单独配置更长的上传时间阈值，进一步降低特殊场景的误报概率

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