tushare 数据入库时间排查报告

> 排查时间：2026-08-01 > 数据来源：7/29-7/31 三个交易日的 fetch_history.json + 8/1 全量实测（40 个品种） > 关联代码：run_data_fetcher.py、tushare_api_proxy.py、tushare_probe.py

---

一、结论摘要

> tushare 当日数据不是 22:00 就完整的，分成三类，入库时间完全不同。

---

二、22:00 拉取失败率（3 个真实交易日）

7/29 22:01  Tier1 成功30 失败4  → 159941, 159985, 510880, 513180
7/30 22:02  Tier1 成功32 失败2  → 510880, 513180
7/31 22:03  Tier1 成功28 失败6  → 159941, 159985, 510880, 511260, 513180, 980092.CNI

22:00 整体成功率：88%~94%（34 个 Tier1 品种里失败 2~6 个）

固定 100% 失败的品种（连续 3 天）：

---

三、"拉不到"是数据丢失还是延迟？

次日全量实测（8/1 周六，即 7/31 +1 天）：对 40 个 tushare 源品种逐个调 fund_daily 查 7/31 数据——

• ✅ 39/40 已含 7/31 数据
• ❌ 仅 000933.SH 无（因为它是指数类，走 index_daily，实测有 7/31 数据）

结论：tushare 数据最终都会入库，只是延迟。 22:00 拉不到的品种，次日凌晨 03:00 自重启 + 08:45 全量拉取已自动覆盖补拉（8/1 凌晨 00:30 Tier2 98/98 全成功可证）。

---

四、唯一真正"永远拉不到"的品种：980092.CNI

调 index_basic(market='CSI') 全量搜索 980092：tushare 根本没有此代码。该品种是 adata 特有指数码，实际已有 adata 源 7/31 数据，tushare 对它永久无效。

✅ 无需修复——_get_source_priority() 中已有 ['tushare', 'adata', 'excel'] 三条 fallback 路径，tushare 失败后 adata 兜底成功。

---

五、历史 Freshness 趋势表（探针品种逐时追踪）

基于 fetch_history.json 记录的 5 个探针品种最后数据日期：

时间          | 399300  | 159915  | 510300  | 513100  | 000933
------------------------------------------------------------------
7/29 09:32   | 07-29  | 07-28  | 07-28  | 07-28  | 07-29   ← 指数当天即有
7/29 12:02   | 07-29  | 07-28  | 07-28  | 07-28  | 07-29   ← ETF停滞
7/29 14:01   | 07-29  | 07-28  | 07-28  | 07-28  | 07-29
7/29 22:01   | 07-29  | 07-29  | 07-28  | 07-28  | 07-29   ← 22点部分ETF才到
---------------------------------------------------------------
7/30 09:33   | 07-30  | 07-29  | 07-29  | 07-29  | 07-30   ← 次日全部补上
...
7/30 22:02   | 07-30  | 07-30  | 07-29  | 07-29  | 07-30   ← 510300/513100又延迟
---------------------------------------------------------------
7/31 09:36   | 07-31  | 07-30  | 07-30  | 07-30  | 07-31
...
7/31 22:03   | 07-31  | 07-31  | 07-30  | 07-30  | 07-31   ← 510300/513100 22点仍未入库
---------------------------------------------------------------
8/1 09:49   | 07-31  | 07-31  | 07-31  | 07-31  | 07-31   ← 全部补齐

关键发现：

• 指数类（399300、000933）→ index_daily 当天 09:30 前已有
• ETF 类（159915）→ fund_daily 当天 22:00 才有（09:30/12:00/14:00 都还停在昨天）
• 固定延迟品种（510300、513100）→ fund_daily 22:00 仍无，次日 09:49 才入库

---

六、探针系统——正在持续观测

已部署 tushare_probe.py + run_tushare_probe.sh，从 8/3 周一启动：

• 采样频率：工作日每 15 分钟一次
• 探针品种（13 个）：覆盖指数类 + 常规 ETF + 固定延迟 ETF 全部三类
• 记录位置：data_cache/tushare_probe_log.csv（自动汇总 tushare_probe_summary.json）
• 目的：积累 3~5 个交易日后，可精确定位每个品种"当日数据最早几点可拉到"

# 管理命令
./run_tushare_probe.sh status   # 查看状态
./run_tushare_probe.sh log      # 实时日志
./run_tushare_probe.sh stop     # 停止

---

七、保底方案（待确认是否执行）

• 22:00 拉完后 23:30 加一次 Tier1 补拉——覆盖 4 个固定延迟品种
• 把主拉时间从 22:00 改为 23:00~23:30——牺牲 1~1.5 小时换近 100% 成功率
• ~~980092.CNI 去掉 tushare 源~~ —— 无需修改，已有 adata fallback 兜底

---

八、与 datayes 等其他数据源的入库时间对比

> 待探针系统积累足够数据后补充。初步推断 datayes（万得同源）可能早于 tushare（城市数据俱乐部代理），但无实证。

---

九、附：探针品种列表

指数类 → index_daily:
  399300.SZ (沪深300)
  000933.SH (中证煤炭)

ETF → fund_daily:
  159915.SZ (创业板)
  510300.SH (沪深300ETF)
  513100.SH (纳指100)
  159941.SZ (纳指ETF)
  159985.SZ (标普ETF)
  510880.SH (红利ETF)
  511260.SH (国债ETF)
  513180.SH (恒生科技)
  513050.SH (中概互联)
  513330.SH (恒生互联网)