SQL报表失败需嵌入容错机制：失败重试须满足幂等性、退避策略（1/3/10秒，最多3次）、分类响应（仅网络/锁超时可重试）；补偿机制依赖report_job_log表状态追踪，自动修复失败任务。

SQL报表统计任务一旦失败，直接导致数据延迟或缺失，影响下游决策。容错机制不是“出了问题再补”，而是从设计阶段就嵌入失败感知、自动重试与确定性补偿能力。

失败重试：有边界、可控制、不雪崩

盲目重试会加重数据库压力，甚至引发连锁超时。重试必须满足三个前提：

• 幂等性保障：SQL语句（尤其是INSERT/UPDATE）需支持重复执行不产生脏数据，例如用INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或MERGE INTO（Oracle/SQL Server）替代裸INSERT；
• 退避策略：首次失败后等待1秒，第二次3秒，第三次10秒，最多3次，避免密集重试；
• 失败分类响应：网络超时、锁等待超时可重试；主键冲突、语法错误、权限不足等应立即终止并告警，不重试。

补偿机制：基于状态追踪的确定性修复

重试失败后，不能靠人工翻日志查原因，而应依赖前置记录的任务状态表实现自动补偿：

• 每次报表执行前，在report_job_log表中插入一条记录，含job_id、report_code、exec_date、status（'running'）、start_time；
• 成功则更新status = 'success'，写入end_time和row_count；
• 失败则更新status = 'failed'，记录error_message和retry_count；
• 补偿作业定时扫描status = 'failed'且retry_count 的记录，按<code>exec_date和report_code重新触发对应SQL逻辑，并递增retry_count。

关键数据隔离：避免“一次失败，全盘污染”

报表SQL若直接写入生产汇总表，失败重试可能造成重复累加。应强制分层写入：

• 临时结果表（如tmp_rpt_user_active_20240501）：每次执行先清空再写入，确保单次结果干净；
• 原子切换视图：用视图指向最新成功的临时表（如CREATE VIEW rpt_user_active AS SELECT * FROM tmp_rpt_user_active_20240501），切换只需改视图定义，毫秒级生效；
• 归档保留：临时表按天保留7天，便于比对和回溯，过期自动清理。

可观测性：让失败“看得见、判得准、跟得住”

没有监控的容错是盲人骑马。必须在SQL执行链路中埋点：

• 每条报表SQL执行前后记录耗时、影响行数、返回码；
• 失败时自动提取错误码（如PostgreSQL的SQLSTATE）、关键上下文（exec_date, report_code）并推送至告警群；
• 提供简单查询接口：SELECT * FROM report_job_log WHERE status = 'failed' ORDER BY start_time DESC LIMIT 20，运营或DBA可立刻定位最近异常。