跳转到主要内容

​
概述

每条 GraphQL 查询会根据所查 Cube、请求行数与聚合复杂度消耗 Credit Units (CU)。Credits 与 REST API 使用同一套计费计划 — 你的 API Key 在两者间通用。
GraphQL API 与 REST Data API 共用同一 API Key 与计费计划。GraphQL 查询消耗的 Credits 计入整体用量。

​
Credit 计算公式

Credits 按 Cube 分别计算，公式如下： 
Credits = BaseCost × LimitFactor × AggregationFactor × MetricFactor
FactorCalculationDescription
BaseCost各 Cube 基础价（见下表）随 Cube 复杂度变化的固定成本
LimitFactorceil(limit / 100)，最小为 1随请求行数缩放
AggregationFactor1.0（无）、1.5（GROUP BY）、2.0（HAVING）使用聚合或 HAVING 过滤时更高
MetricFactor1.0 + (metric_count × 0.2)每增加一个 metric（如 count、sum）都会提高
在默认 limit（25 行）且无聚合的简单查询中，通常只支付基础成本。提高行数或增加聚合类 metric 时，Credits 会上升。

​
计算示例

BaseCost = 50, LimitFactor = ceil(10/100) = 1
AggregationFactor = 1.0, MetricFactor = 1.0
Credits = 50 × 1 × 1.0 × 1.0 = 50 CU

BaseCost = 50, LimitFactor = ceil(500/100) = 5
AggregationFactor = 1.0, MetricFactor = 1.0
Credits = 50 × 5 × 1.0 × 1.0 = 250 CU

BaseCost = 50, LimitFactor = ceil(500/100) = 5
AggregationFactor = 1.5 (GROUP BY), MetricFactor = 1.0 + 2×0.2 = 1.4
Credits = 50 × 5 × 1.5 × 1.4 = 525 CU

​
各 Cube 基础成本

CubeBase Cost (CU)说明
DEXTrades50维度最多、体量最大的表
DEXTradeByTokens50与 DEXTrades 同源数据
DEXPoolEvents30流动性事件
Pairs30OHLC K 线数据（Trading 组）
Tokens30代币成交统计（Trading 组）
WalletTokenPnL25DWS 汇总
Transfers15
BalanceUpdates10
Events、Calls20EVM 专属事件/调用追踪
Instructions20Solana 专属
PredictionTrades20预测市场数据
其余所有 Cube20默认基础成本
基础成本反映查询复杂度与各 Cube 底层数据规模。extensions.credits 中返回的实际 Cube 名称由服务端决定 — 请以响应值为计费依据。

​
响应：extensions.credits

每条 GraphQL 响应都会在 extensions 中附带 Credits 消耗详情： 
{
  "data": {
    "DEXTrades": [ ... ]
  },
  "extensions": {
    "credits": {
      "total": 50,
      "cubes": [
        {
          "cube": "DEXTrades",
          "credits": 50,
          "row_count": 10
        }
      ]
    }
  }
}
FieldTypeDescription
totalInt整条查询消耗的 Credits 合计
cubesArray按 Cube 拆分
cubes[].cubeStringCube 名称
cubes[].creditsInt该 Cube 计费的 Credits
cubes[].row_countInt返回行数
在发生扣费（即 total > 0）时会出现 extensions.credits。即使返回 0 行，仍会收取基础成本。

​
在 IDE 中查看用量

GraphQL IDE 状态栏会在每次查询后显示 Credits 消耗：
  • CU 指示：显示消耗的 CU 总数（例如 50 CU）
  • Latency：请求耗时（毫秒）
  • Response size：响应体大小

​
优化 Credits 使用的建议

少选字段

只请求需要的维度字段。字段越少，处理的数据量通常越小。

合理 limit

在业务允许范围内尽量压低 limit.count。Credits 随 ceil(limit / 100) 缩放。

优先预聚合 Cube

需要汇总数据时，优先使用 DWM/DWS Cube（如 Pairs、Tokens、TokenHolders），而不是在 DWD Cube（如 DEXTrades）上堆 metrics。

​
相关文档

计费与 Units 总览

ChainStream 计费计划、单位配额与支付方式概览。

Metrics 与聚合

了解聚合 metrics 如何影响查询 Credits。