适用范围与取证输入
本文用于 Apache Doris 3.x 的普通 Stream Load 和 Broker Load 故障诊断，重点检查“客户端超时但数据可能已提交”。Flink Connector 的两阶段提交、Group Commit 与多表事务需要另外核对连接器和补丁版本，本篇状态判断不能代替它们的协议。示例保持 PENDING，仅给出检查步骤，不执行导入、取消或重放。
开始前固定数据库、表、批次 label、输入文件摘要、源端位点、TxnId、首次请求和最后响应时间。保留 HTTP 状态、JSON 正文与客户端退出信息三个层次，脱敏保存地址与错误样本。客户端没收到完整响应属于结果未知，不能直接写成导入失败。
把接收、提交和可见分开
Stream Load 经由 FE 接入和协调，实际写入涉及 BE；一次导入会经历事务准备、数据写入、提交和发布。网络断开可能发生在任意阶段。HTTP 成功码只代表接口响应，需要继续解释 JSON 中的状态；客户端传完文件也不等于业务已能查询。
普通 Stream Load 返回 Success 表示成功，Publish Timeout 表示导入已完成但可能尚未可见，Label Already Exists 表示该 label 已被使用，Fail 表示失败。遇到发布超时应查原事务，不能换 label 再导一次。这些返回字段见 Stream Load 手册。
使用原事务定位不确定结果
下例中的 label 必须替换为从原始请求记录获得的值：
SHOW TRANSACTION FROM analytics
WHERE LABEL = 'orders_20260901_batch0042';也可按响应中已知的事务编号精确查询：
SHOW TRANSACTION FROM analytics WHERE ID = 4005;TransactionStatus=PREPARE 表示准备阶段；COMMITTED 表示已提交但尚未可见；VISIBLE 表示成功且可见；ABORTED 表示失败。联看 PrepareTime、CommitTime、FinishTime 和 Reason，不要把 COMMITTED 当成可以重放的失败。字段与权限要求见 SHOW TRANSACTION。
若查无记录，应先检查数据库、权限、label 拼写和保留期。空结果没有足够信息证明“从未写入”，此时需要结合原日志与有限业务核对，暂停自动重试。
区分三种状态记录
Broker Load 是异步任务，可按已知 label 查看任务状态：
SHOW LOAD FROM analytics
WHERE LABEL = 'orders_20260901_batch0042'
LIMIT 5;PENDING、ETL、LOADING、FINISHED、CANCELLED 是任务状态，不能直接拿来替换事务的 COMMITTED/VISIBLE。应同时保存任务与事务标识，避免同名字段造成混淆，见 SHOW LOAD。
Stream Load 历史可用 SHOW STREAM LOAD，但 BE 默认不记录这类历史，是否有记录取决于 enable_stream_load_record 等现场配置。下例仅在已启用记录时有诊断价值，不应为了这次排障临时全局改配置：
SHOW STREAM LOAD FROM analytics
WHERE LABEL = 'orders_20260901_batch0042'
LIMIT 5;没有历史记录不等于导入失败，详见 SHOW STREAM LOAD。
解释行数和过滤原因
假设已保存的响应含总行数 1000、加载行数 970、质量过滤 20、条件过滤 10，这只是解释性样例，不是本环境结果。先分别查看 NumberFilteredRows 与 NumberUnselectedRows：前者反映质量问题，后者反映导入 WHERE 条件，两者责任不同。
对照输入映射、分隔符、编码、时区、空值与字段精度，挑选脱敏错误行核验。不要提高 max_filter_ratio 来消除失败；放宽比例意味着允许丢弃一部分输入，必须由数据契约定义。行数看似吻合也可能是列错位或时区错误，金额合计、关键标识与分区日期还要单独检查。
重试必须保持批次身份
普通 Stream Load 用 label 辅助避免同一批次重复提交，调用方需要稳定地把它关联到输入摘要和源端范围。同 label 对应不同文件属于输入冲突；同一文件每次随机生成 label 则失去这层保护。label 记录有保留边界，不能作为永久业务去重机制。
Duplicate 表重放可能增加行，Aggregate 的 SUM 列可能重复累计，Unique 表虽按 Key 覆盖，仍可能因为旧事件乱序而反写较新的状态。是否可以重试，要同时证明原事务结果、输入是否一致以及模型是否接受重放。模型关系见 Doris 架构与数据模型。
根据阶段定位性能问题
优先使用已保存响应的 ReadDataTimeMs、WriteDataTimeMs 和 CommitAndPublishTimeMs，比较相近批次与相同并发窗口。读取长可能涉及客户端上传；写入长可能涉及分布、刷盘或存储压力；提交发布长则需要关联协调节点、事务与相关副本状态。这些是收窄方向，不是根据单一耗时直接定根因。
如果小批次越来越慢，观察版本增长、合并积压、活跃事务和上游并发是否同时上升。存算分离环境还应检查 MS、FDB 与远端存储链路，不能只查 BE 本地磁盘。阶段计时可能重叠，不能把所有字段简单相加当成端到端耗时。
用有界查询验证业务可见性
在事务已确认可见后，按已知分区与少量业务键核对：
SELECT order_id, status, amount, source_version
FROM analytics.orders_current
WHERE order_date = '2026-09-01'
AND tenant_id = 42
AND order_id IN (90001, 90002, 90003)
LIMIT 10;执行前确认字段与分区存在，并先用 EXPLAIN 检查扫描范围。LIMIT 不保证扫描成本有界；若日期不是分区列，应改用现场已确认的范围。本查询证明的是样本在当前读取窗口可见，并不代表整批无遗漏。全批验收应在隔离或受控资源组内比较源端条数、业务金额和关键键集合。
验收、停止与回退
导入事故的结案条件包括：原事务终态明确、批次身份可追溯、过滤记录有解释、源端位点与目标可见数据一致，以及积压趋势恢复。若历史已过期、源端摘要不明、同 label 输入冲突或发布积压持续扩大，应停止重放与扩并发，交接未知批次清单。
已 VISIBLE 的数据不能依靠取消原任务撤销；恢复需要按模型制定补偿、重建或来源重放方案。只读诊断无需数据回退，重试前应保留原输入和当前结果证据。对资源瓶颈继续阅读 Doris Query Profile 调优。