API只返回十个统计桶，并不意味着数据库只处理十条记录。如果先把整个仓库的记录分组、排序，再截取一页，返回体可以很小，聚合前的工作却仍然很大。优化要同时看输入范围、执行计划和接口语义，而不只是JSON大小。

GitHub在10月14日的星标历史API工程文章中讨论了这个取舍。本篇用90条没有用户身份的合成记录，复现“先聚合后分页”与“先限定时间再聚合”的结果关系，并解释时间窗口和历史口径的边界。没有请求真实星标数据，也没有复现GitHub的性能测试。Read in English。

这次改动回答的是趋势问题

Google News收录的GitHub原文发表于2026年10月14日。它介绍用聚合历史接口服务趋势查询，不再为画曲线而返回个人身份，并把时间范围过滤放在分组之前。原文的生产数据和请求减少数字属于GitHub自报，本文没有重新测量。

这一方向值得借鉴，但不能把标题里的请求数量变化直接用作其他数据库的提速比例。请求次数、传输字节、候选行、实际扫描行、CPU与等待时间是不同量，它们可能同时变化，也可能只有其中一项变化。

下文只讨论仓库内合成记录的分组。真实接口的参数、时间边界和权限应核对官方API说明，不要把教学SQL当成GitHub服务器实现。

LIMIT约束输出，不自动约束分组输入

设要查询某仓库按天计数，再返回中间十天。一个直观写法是先WHERE限定仓库，再GROUP BY day、ORDER BY day，最后LIMIT与OFFSET。逻辑上，一页输出是已经形成的分组结果的片段。

另一种写法把已知的日范围也放进WHERE，再对命中的记录分组。两者在特定数据和窗口下可以返回同样结果，但前者的输出数量本身没有表达第二种写法的输入边界。

SQL逻辑顺序不是对每个数据库物理执行顺序的保证。优化器可能采用不同计划，索引和统计信息也会改变结果。应查看真实执行计划，而不是从语句文本直接宣布一定扫描了多少行。

一个能本地运行的范围例子

下面在内存SQLite中生成30天、每天三条记录，共90条。day只是人为编号，不是GitHub时间戳。第一条查询跳过前十个日桶再取十个，第二条直接限定10≤day<20；示例特意每天都有记录，以便两种表达选择同一组天。

# Synthetic current rows; no GitHub API calls or user identities.
import sqlite3

con = sqlite3.connect(":memory:")
con.execute("CREATE TABLE stars(repo TEXT, day INTEGER)")
con.executemany("INSERT INTO stars VALUES (?,?)",
                [("demo",day) for day in range(30) for _ in range(3)])
con.execute("CREATE INDEX stars_repo_day ON stars(repo,day)")

all_then_page = """SELECT day,COUNT(*) FROM stars
WHERE repo='demo' GROUP BY day ORDER BY day LIMIT 10 OFFSET 10"""
range_then_group = """SELECT day,COUNT(*) FROM stars
WHERE repo='demo' AND day>=10 AND day<20
GROUP BY day ORDER BY day"""
a = con.execute(all_then_page).fetchall()
b = con.execute(range_then_group).fetchall()
assert a == b
assert len(b) == 10
assert all(count == 3 for day,count in b)
assert sum(count for day,count in b) == 30
assert con.execute("SELECT COUNT(*) FROM stars WHERE repo='demo'").fetchone()[0] == 90
assert con.execute("SELECT COUNT(*) FROM stars WHERE repo='demo' AND day>=10 AND day<20").fetchone()[0] == 30
assert b[-1][0] == 19
assert con.execute("SELECT day FROM stars WHERE day>=30").fetchall() == []
print("Synthetic range and grouping checks passed")
print(con.execute("EXPLAIN QUERY PLAN " + range_then_group).fetchall())

本地八项检查通过：两种查询结果相同、十个日桶各计数三、总计三十条命中记录，以及上界与空范围。代码还输出范围查询的执行计划。本次运行显示使用覆盖索引的SEARCH，并带仓库与day范围条件；其他版本或数据仍需独立查看计划。

九十是合成总记录数，三十是满足范围条件的记录数，十是返回桶数。它们不是“实际扫描行数”的通用测量方法，更不是速度提升三倍的证明。此处没有进行延迟基准，数据规模也不足以支持生产性能结论。

按结果条数分页，与按日历窗口分页不同

如果某些天没有记录，LIMIT十个桶表示十个有数据的日桶，不一定对应连续十个日历日。显式范围10≤day<20则始终描述那段时间；空日是否补零，是另一个需要写进接口的约定。

因此，不能把例子中两种查询相同推广成任意数据都等价。时间窗口分页适合回答“这几周发生什么”，而按已有结果分页可能跨过没有数据的日期。选哪一种，要从调用者的问题出发。

GitHub接口文档说明其历史结果按周组织、向较早历史翻页，并提供每天计数；一次响应最多包含30周，分页单位是周，不是单条星标；周与日边界不能默认当成UTC。对图表调用者，顺序、边界与空桶规则都应参与解析和测试。

索引范围有用，但不是固定成本保证

教学索引(repo,day)把仓库和日范围放在同一条访问路径上。它让数据库有机会按仓库和时间定位候选范围，而不是先取出无关日期再分组。是否实际采用、是否需要额外排序，要结合执行计划确认。

有范围不等于范围内记录数有上限。一周可能很稀疏，也可能出现异常密集的新增。即使接口总是返回七个日计数，计算这些计数的工作也可能不同。接口设计还需要考虑密集窗口与资源限制。

对自己的服务，可记录计划、实际行数指标、耗时与并发条件，再比较改动前后。只测响应大小，不能回答数据库是否省了工作；只看一次热缓存结果，也不足以说明稳定表现。

当前存量曲线，不是完整历史事件日志

原文指出星标模型保存的是当前仍存在的记录，取消星标会移除相应记录。因此，从当前记录的创建时间做历史分组，不能凭空恢复所有过去发生过又被删除的事件。这是数据模型语义，不是分页能修复的问题。

用一个虚构例子理解：第1天有两条创建记录，其中一条第3天被移除。第4天只看当前存量再按创建日分组，第1天可能只剩一条。它与第1天实际发生过两次创建，并不是同一个统计问题。

展示图表时应写清到底是当前存量的创建时间分布、累计创建事件，还是某时刻快照。不能把它们都命名为“历史总量”，再根据曲线变化做出超出数据支持的结论。

先明确需求，再决定要不要明细

如果业务只需要日计数，先返回完整个人列表再丢掉身份，会把不需要的数据带进调用方。聚合接口可以减少这种额外处理与保留，但它仍需准确说明统计对象、分组边界和可获得范围。

这不是说所有明细接口都没有用途，而是需求应决定数据形态。审计某条合法授权记录与绘制公开趋势，可能需要不同接口和访问范围。本文没有采集用户列表，也不提供绕过访问限制的方法。

与按需源码检出一样，省下工作往往来自更准确地表达需要什么。这里需要的是某个时间范围的趋势，而不是先取得所有明细再处理。

把三个边界放进测试

第一是时间边界：下界包含、上界排除是否与客户端一致。第二是稀疏边界：无记录的日期如何表达。第三是状态边界：删除或取消行为会怎样改变旧桶。只测试正常密集数据，会遗漏后两类语义差异。

再把输出数量与执行成本分开报告。这个小例子证明的是给定数据下查询结果和范围条件；生产系统的成本需要生产规模和实际计划来回答。若这份SQL例子与接口边界分析帮你排查了聚合查询，欢迎通过文末支持区自愿支持。

来源与补发说明

经Google News发现并核对10月14日GitHub工程原文及官方历史API文档。两幅图、90条合成记录和SQLite检查为原创教学内容；未调用真实GitHub数据接口，未执行生产性能测评。本篇保留2026年10月19日22:00文章日期，实际于当日稍后补发。