order_site

1,245 Commits 8 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
yml2213	d90c066888	feat(cost-center): 成本异常 60 天归档 cost_exceptions 只增不减：本地快照 260,253 行（resolved 151,939 / open 108,314），已处理的行只是审计痕迹，留在热表会拖慢「状态 + 时间」分页，并让唯一索引持续膨胀。 - 迁移 108：新增 cost_exceptions_archive（保留原 id 与时间字段，加 archived_at），热表补部分索引 idx_cost_exceptions_archivable (COALESCE(resolved_at, created_at)) WHERE status <> 'open'，让每日任务不扫全表； - cost-exception-archive-service：只归档 status <> 'open' 且超期的行，每批 1000 行， DELETE ... RETURNING + INSERT 在同一语句内完成，单批原子，不存在「删了没归档」； - data-retention 每日任务接入；保留期走 COST_EXCEPTION_RETENTION_DAYS（默认 60）； - 新增 npm run cost-exceptions:archive（--dry-run / --days / --batch-size）。为什么 open 行不归档：open 是待办队列，超期不等于已解决，归档等于把问题藏起来。验证： - 3 条 resolved 回拨到 90 天前 → 归档 3 条，热表 resolved 151,939 → 151,936； - 1 条 open 回拨到 90 天前 → 仍在热表，未被归档； - 归档表保留原 id 与时间，archived_at 记录归档时刻； - 恢复测试数据后计数回到 151,939 / 108,314。	2026-10-25 12:09:20 +08:00
yml2213andCursor	1239393fc2	perf: 筛选统计去掉 JSON 兜底，并补上 orders 覆盖索引去掉 work_orders 堆访问后，JOIN 会把 orders 整表扫进 Hash Right Join。领取页在快照新鲜时不再打上游；快手出网统一 10 秒超时。倒计时改为自适应间隔。 Co-authored-by: Cursor <cursoragent@cursor.com>	2026-10-01 15:05:38 +08:00
yml2213	1ca15e9025	perf(db): 统计金额落到列上、会话刷新节流、补齐保留与内存治理背景：生产 32 天内 >500ms 慢查询从 2.4k/天涨到 1.3 万/天（09-26 尖峰 14.3 万）， pg_stat_statements 显示后台工单列表族占 57%、打手端 visible_orders 占 27%；同时 backend 容器十天从 194MB 涨到 754MB(768MB 限额的 98%)，贴顶后整体变慢。 1. 新增迁移 083：work_orders 增加派生列 source_order_amount_fen，并从 material_json.source.orderAmountFen 回填（只认 15 位以内整数，与 JS/SQL 口径一致）。统计查询原来每行要解析 1.2KB JSON（全表约 132MB）且同一表达式求值两次，生产实测 3.5~4.4 秒；改走派生列后 COALESCE 短路，未命中列的行才回退 JSON/orders.total_amount，口径与改造前完全一致。写入点：createWorkOrder / updateWorkOrder 各一处，并加静态守卫。 2. worker_sessions.last_seen_at 从"每个请求都写"改为"5 分钟才写一次"： 32 天被写了 3300 万次（占 DB 总时间 2.8%，并堆出 14% 死元组）。仍用一条语句返回鉴权有效性（EXISTS target AS valid），不能因为不写就让上层 401。 3. 保留策略补上 work_order_events（71.7 万行 / 269MB，此前完全没纳入清理，只增不减），新增配置 retention.workOrderEventDays（默认 180 天）与 WORK_ORDER_EVENT_RETENTION_DAYS 出口。 4. 内存治理：compose 后端限额 768m→1g 并显式设置 V8 老生代上限（--max-old-space-size=768），避免贴 cgroup 上限后 GC 抖动；新增每 10 分钟的进程内存快照日志（rss/heapUsed/heapLimit），用于区分"正常 GC 曲线"与"真泄漏"。 5. 限流桶加 5 万条硬上限：key 里含请求体字段（collect 的 orderNo）时可被构造成高基数，只按过期清理挡不住内存增长。验证：后端 530 项单测全绿（新增 11 项，含派生列/会话/保留的静态守卫与解析函数单测）。	2026-10-01 12:55:09 +08:00

Author

SHA1

Message

Date

yml2213

d90c066888

feat(cost-center): 成本异常 60 天归档

cost_exceptions 只增不减：本地快照 260,253 行（resolved 151,939 / open 108,314），
已处理的行只是审计痕迹，留在热表会拖慢「状态 + 时间」分页，并让唯一索引持续膨胀。

- 迁移 108：新增 cost_exceptions_archive（保留原 id 与时间字段，加 archived_at），
  热表补部分索引 idx_cost_exceptions_archivable
  (COALESCE(resolved_at, created_at)) WHERE status <> 'open'，让每日任务不扫全表；
- cost-exception-archive-service：只归档 status <> 'open' 且超期的行，每批 1000 行，
  DELETE ... RETURNING + INSERT 在同一语句内完成，单批原子，不存在「删了没归档」；
- data-retention 每日任务接入；保留期走 COST_EXCEPTION_RETENTION_DAYS（默认 60）；
- 新增 npm run cost-exceptions:archive（--dry-run / --days / --batch-size）。

为什么 open 行不归档：open 是待办队列，超期不等于已解决，归档等于把问题藏起来。

验证：
- 3 条 resolved 回拨到 90 天前 → 归档 3 条，热表 resolved 151,939 → 151,936；
- 1 条 open 回拨到 90 天前 → 仍在热表，未被归档；
- 归档表保留原 id 与时间，archived_at 记录归档时刻；
- 恢复测试数据后计数回到 151,939 / 108,314。

2026-10-25 12:09:20 +08:00

yml2213andCursor

1239393fc2

perf: 筛选统计去掉 JSON 兜底，并补上 orders 覆盖索引

去掉 work_orders 堆访问后，JOIN 会把 orders 整表扫进 Hash Right Join。
领取页在快照新鲜时不再打上游；快手出网统一 10 秒超时。倒计时改为自适应间隔。

Co-authored-by: Cursor <cursoragent@cursor.com>

2026-10-01 15:05:38 +08:00

yml2213

1ca15e9025

perf(db): 统计金额落到列上、会话刷新节流、补齐保留与内存治理

背景：生产 32 天内 >500ms 慢查询从 2.4k/天涨到 1.3 万/天（09-26 尖峰 14.3 万），
pg_stat_statements 显示后台工单列表族占 57%、打手端 visible_orders 占 27%；
同时 backend 容器十天从 194MB 涨到 754MB(768MB 限额的 98%)，贴顶后整体变慢。

1. 新增迁移 083：work_orders 增加派生列 source_order_amount_fen，并从
   material_json.source.orderAmountFen 回填（只认 15 位以内整数，与 JS/SQL 口径一致）。
   统计查询原来每行要解析 1.2KB JSON（全表约 132MB）且同一表达式求值两次，
   生产实测 3.5~4.4 秒；改走派生列后 COALESCE 短路，未命中列的行才回退 JSON/orders.total_amount，
   口径与改造前完全一致。写入点：createWorkOrder / updateWorkOrder 各一处，并加静态守卫。
2. worker_sessions.last_seen_at 从"每个请求都写"改为"5 分钟才写一次"：
   32 天被写了 3300 万次（占 DB 总时间 2.8%，并堆出 14% 死元组）。仍用一条语句返回鉴权有效性
   （EXISTS target AS valid），不能因为不写就让上层 401。
3. 保留策略补上 work_order_events（71.7 万行 / 269MB，此前完全没纳入清理，只增不减），
   新增配置 retention.workOrderEventDays（默认 180 天）与 WORK_ORDER_EVENT_RETENTION_DAYS 出口。
4. 内存治理：compose 后端限额 768m→1g 并显式设置 V8 老生代上限（--max-old-space-size=768），
   避免贴 cgroup 上限后 GC 抖动；新增每 10 分钟的进程内存快照日志（rss/heapUsed/heapLimit），
   用于区分"正常 GC 曲线"与"真泄漏"。
5. 限流桶加 5 万条硬上限：key 里含请求体字段（collect 的 orderNo）时可被构造成高基数，
   只按过期清理挡不住内存增长。

验证：后端 530 项单测全绿（新增 11 项，含派生列/会话/保留的静态守卫与解析函数单测）。

2026-10-01 12:55:09 +08:00