TickDB 数据质量怎么样？用 15 次真实调用，看懂行情选型的 6 个检查点

接入行情 API 后，程序能拿到价格，只能说明第一步走通了。

真正影响使用的是另外一些问题：历史 K 线有没有漏分钟？1 分钟数据合成的 5 分钟线，能否与接口直接返回的结果对上？一个“昨天的价格”，究竟是数据没有更新，还是今天本来就休市？AI 助手引用的“最新价”，到底属于常规时段还是盘前？

为了回答这些问题，我们在 2026 年 9 月 25 日进行了一次 TickDB 小样本实测，保留全部请求参数、原始返回和计算脚本。先给结论：本次样本支持将 TickDB 纳入行情看板、AI 行情查询和短周期研究工具的候选；它还不足以证明长期数据完整性、交易所级低延迟或价格准确率。

最值得关注的结果并不是“全部通过”，而是三件具体的事：两种加密资产的小时窗口数据能够完整对齐；不同周期的 OHLCV 能够逐项核对；股票行情必须结合交易日与交易时段解读。

这次到底测了什么

采样时间为北京时间 2026-09-25 20:39:55.596—20:41:25.703，对应 UTC 12:39:55.596—12:41:25.703。使用已配置鉴权的 TickDB MCP，在 macOS 26.2、arm64 的桌面环境中串行调用，没有并发压测，也没有把模型生成答案的耗时算入请求计时。

测试范围如下：

一共发出 15 次工具调用，14 次成功，1 次因我们传错日期格式被拒绝。后文会单独解释这次失败。

历史分钟窗口固定为当日 UTC 11:00—11:59（北京时间 19:00—19:59），请求终点为 11:59:59.999。这个窗口在采样前已经结束。跨周期核对只比较同一标的、同一窗口、返回标记同为 adjust=none 的数据，不跨市场混加成交量。

这是一份有限范围的接入检查，不是对全市场、所有套餐或所有交易日的质量认证。

检查点一：字段齐全，要按业务需要判断

这次 15 条快照记录中，选定的 9 项核心字段均存在且非空：标的代码、产品类型、最新价、数据时间戳、成交量、最高价、最低价、价格变化和变化百分比。

历史样本包含 149 根不同“标的＋周期＋时间”组合的 K 线：120 根加密资产分钟线、24 根五分钟线、5 根 A 股日线。检查的时间、开高低收、成交量、成交额 7 项字段全部存在且非空，数值字段可以按十进制定点数解析。

但这不等于“所有字段完整”。本次快照里没有出现 bid_price、ask_price；官方快照文档把它们标为“如有”。因此，若你做的是价格展示，这批返回满足了本次选定的基础字段检查；若你做买卖价差、盘口信号或模拟成交，就不能把 last_price 当作盘口的替代品，需要另测对应数据与账户权限。TickDB 行情快照文档

对 AI 应用也一样：让模型说出一个数字很容易，让它同时说出标的、时段、数据时间和字段含义，才是可靠引用行情的起点。

检查点二：时间戳很旧，先问市场在做什么

同一轮请求里，几个市场呈现了完全不同的时间状态。以下是第一轮快照的实际返回，时间统一换算为北京时间：

表中价格保留各标的自身计价口径，不用于跨资产价格比较。

A 股这一条尤其容易误判。 单看时间，快照已经过去约 29 小时。但交易日历接口查询 9 月 24—25 日，只返回 9 月 24 日；上交所官方休市安排也明确，2026 年 9 月 25—27 日中秋休市。这是不能把自然日空缺直接算成数据丢失的实例。上交所 2026 年休市安排

还要留意，A 股返回的时间落在 15:30:01，本文没有把它解释为该股票最后一笔成交发生的时刻。已读取的快照文档只称它为“数据时间戳”，并未为本次所有市场给出统一的交易所事件时间定义。需要交易所事件时间的应用，应继续确认这一语义。

美股则是另一个问题：选错了字段。 采样时约为纽约 08:40，交易时段接口返回的盘前区间是当地 04:00—09:30。本次 AAPL 返回中，顶层报价仍对应前一常规时段，同时 pre_market_quote 已经更新。AI 如果只读顶层 last_price，就可能漏掉当前盘前信息。这里依据的是本次实际响应结构；不能由此推断所有美股、所有权限都必然返回相同扩展字段。

!image.png

图 1｜解释示意：判断行情是否陈旧，应先确认交易日、所处时段，再选择对应报价字段。不是产品界面或实测截图。

检查点三：接口响应耗时，与行情新鲜度分开算

这次在工具调用前后记时，15 次调用的往返耗时为：最小 613 毫秒，中位数 816 毫秒，最大 5133 毫秒，包含那次参数错误请求。

这个计时覆盖客户端到 MCP 服务再返回的工具调用路径，无法拆出 TickDB 底层 REST 服务本身的处理时间。因此，它适合帮助判断本次 AI 工具交互的体验，不适合作为 REST 性能榜单，更不能称为“交易所行情延迟”。

我们还计算了另一项值：

观察到的数据年龄 = 工具返回时刻 − 响应中的数据时间戳。

三轮 BTCUSDT 的结果分别为 422、685、1232 毫秒，ETHUSDT 为 419、688、1229 毫秒。AAPL 的盘前字段对应 5430、6696、8239 毫秒。

!image.png

图 2｜由原始响应与工具返回时刻计算。北京时间 2026-09-25 20:40—20:41，3 轮、每轮 2 个标的。数据年龄不是交易所级端到端延迟；计算依赖两端时钟。

这组数值说明，在这几个采样点，返回的加密资产时间戳接近工具接收时刻。它不能证明行情在交易所产生后用了多少毫秒抵达用户：我们没有交易所侧同一事件的可信对照时间，也没有验证工具执行环境与上游时间戳的时钟同步误差。盘前报价年龄还可能受成交活跃度影响。

如果你的场景是 AI 查询与研究助手，这些值可以作为试用记录；如果你需要严格的亚秒决策或延迟保证，就应使用自己的部署环境、可验证时钟和事件基准另做测试。

检查点四：历史序列连续，不等于价格已经被证明准确

BTCUSDT 和 ETHUSDT 各返回 60 根分钟线，恰好覆盖指定的 60 个分钟时间点；各自 12 根五分钟线也覆盖了对应网格。这个已结束窗口内，未发现时间点缺失、重复或乱序。

所有 149 根历史样本都通过了以下基本规则：

low ≤ min(open, close) ≤ max(open, close) ≤ high；成交量与成交额不为负。

这些是“内部自洽”的证据。例如，一根线的收盘价高于最高价，就值得排查；但一根结构完全自洽的 K 线，也可能与交易所原始记录存在偏差。没有独立的权威价格基准，本次不能给出价格准确率。

同样，本次只核验了两种加密资产一个小时的网格，不是多年历史完整性测试。股票分钟线则需要先建立交易日与交易时段网格，区分午休、停牌、无成交、权限限制、分页截断和真实缺数，不能套用连续 24 小时的分钟计数方法。

历史接口文档规定单次最多 1000 条。本次请求每个分钟样本只取 60 条，不涉及跨页，因此不能声称已验证大批量回补与分页边界。TickDB 历史 K 线文档

检查点五：把 1 分钟线合成 5 分钟线，再逐项核对

对于做指标、图表和研究的开发者，比“看起来像一根 K 线”更有价值的检查，是验证不同周期是否讲述同一段行情。

我们按相同起始时间，将连续 5 根分钟线合成一根五分钟线：开盘取第一根，收盘取最后一根，最高取最大值，最低取最小值，成交量和成交额分别求和。数值使用 Decimal 计算，避免二进制浮点误差。

结果是：两种资产共 24 根五分钟线，6 个字段共 144 项比较，全部与接口直接返回值相等。 这是同一历史接口不同周期之间的一致性检查。

以 BTCUSDT 在 UTC 11:00 开始的五分钟窗口为例：

同一 BTC 历史窗口随后复查一次，返回的 60 根线与第一次解析后的数据相同。这只能说明本次两次读取稳定，不是历史永不修订的证明。

另外，我们做了一项真正的跨接口核对：600519.SH 最新历史日线的收盘价 1237，与快照的 last_price 相同；开高低、成交量、成交额也逐项相等，共 6 项。比较针对同一已结束交易日，未进行单位换算；这种相等不验证成交量的外部单位定义，也不保证盘中不同步调用的快照与 K 线必然相等。

!image.png

图 3｜解释示意：历史核对要固定同一已结束窗口；正在形成的 K 线应单独处理。图中的图形不代表真实价格或测试数值。

本次实时分钟线返回的是 UTC 12:41 开始、采样时尚未结束的窗口。它没有混入上述历史通过数。官方文档也分别提供历史 K 线与实时 K 线接口，提醒当前周期仍会更新，不建议将实时线直接用于固定历史统计。TickDB 实时 K 线文档

检查点六：成功率要把请求错误和服务失败分开

本次调用成功数是 14/15。唯一失败来自我们把交易日历日期写成了 2026-09-24，接口返回错误码 2001，明确要求 YYYYMMDD。更正为 20260924 后成功。

所以，完整记录应写成：15 次尝试，14 次成功，1 次调用方参数错误；格式正确的 14 次调用未观察到服务错误。 不能删掉失败样本，也不能把它解释为 TickDB 的服务故障。交易日历文档已经写明日期格式，这是调用端应承担的校验责任。TickDB 交易日历文档

如此短的串行样本没有覆盖高峰期、网络断连、限频恢复或长时间运行，不能据此推出月度可用性或 SLA。

什么条件下，值得把 TickDB 放进候选名单

官方文档提供多市场统一接口、REST、WebSocket 与 MCP 等接入方式。本次实际验证到的是 MCP 下的五个标的和上述接口子集，并未测试 WebSocket。TickDB 文档

结合这次结果，可以按实际工作做选择：

如果你希望以一套接入方式搭建行情看板或 AI 工具，并愿意在应用层处理字段语义、交易日历和失败状态，TickDB 值得进行针对性试用。它在本次测试中的可用价值是可读取的统一数据，以及可以进行交叉检查的历史序列。

如果项目必须依赖交易所事件时间、确定的盘口覆盖、可承诺的端到端延迟，或者要立即认定多年回测数据完整，这篇测试不足以支持直接定案。

还需确认账户权益。历史深度、请求频率与可用数据受套餐条件影响，本次账户能够返回这些数据，不代表所有试用账户都具有相同权限。本文不根据一次成功调用推断免费范围，也不替代你的授权和采购核验。TickDB 套餐说明

最实用的下一步是：从 TickDB 文档入口 确认你要用的接口，在自己的品种池中选几只活跃与低活跃标的，覆盖盘中、收盘和节假日，复用“字段—时间—连续性—一致性—失败处理”这条检查路径。只有它在你的业务条件下通过，选型才算向前走了一步。

通过 TickDB API 获取实时行情数据

一个 API 接入外汇、加密货币、美股、港股、A股、贵金属和全球指数的实时行情。支持 WebSocket 低延迟推送，免费开始使用。