mirror of
https://github.com/Wei-Shaw/sub2api.git
synced 2026-10-14 12:02:27 +08:00
HuntercodeT
18d483c2a1
GET /api/v1/admin/groups/usage-summary 在有一定数据量的库上会退化成
usage_logs 全表扫。根因是 getAllGroupUsageSummaryFromRollups 里，tail CTE
的 created_at 下界 state.tail_start 由同一条 SQL 的 state CTE 算出、再用
CROSS JOIN 交给 tail：这个值对 planner 来说要到运行期才知道，既进不了
index cond，也估不准选择性，于是只能顺序扫全表再逐行过滤。
生产实测（1721 万行 usage_logs / PostgreSQL 17）：
Nested Loop (actual time=28161..48334 rows=34788)
Join Filter: (ul.created_at >= state_1.tail_start)
Rows Removed by Join Filter: 17178082
-> Seq Scan on usage_logs (actual time=0.030..47567 rows=17212870)
Buffers: shared hit=12863 read=951875
Execution Time: 48720 ms
改成先读一次水位行、在 Go 侧算出 tail_start / closed_before / retained
日期，再把它们当查询参数传进来。同一套数据上：
Index Scan using idx_usage_logs_created_at on usage_logs
Index Cond: (created_at >= $7)
Execution Time: 34 ms
水位有效性的判定（恰好一行、时区名与配置一致、水位不在未来）和无效时
退化成从 epoch 全量重算的行为，与原先 SQL 里 state_values / CASE WHEN
valid 的分支逐条对应，结果口径不变。
另外读取水位的语句不加锁，不参与 #6976 那条 FOR UPDATE / FOR KEY SHARE
的阻塞链。