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可立刻定位最近异常。
