|
|
d735de7864
|
修复发布冷缓存时店铺筛选退回大范围扫描
|
2026-10-19 18:07:12 +08:00 |
|
|
|
17429d65ab
|
perf(财务): 减少大表扫描与重复重算，串行受限导出
|
2026-10-19 17:53:14 +08:00 |
|
|
|
1f4f6f48d4
|
优化财务资源：减少重复扫描、隔离重型任务、约束系统日志 (#390)
|
2026-10-19 14:56:54 +08:00 |
|
|
|
c4a976751d
|
修复订单售后页面一直转圈：店铺候选改成定时预热
上一次把店铺候选的完整计算放在 app()->terminating() 里，但服务器是 mod_php，
响应要等整个请求（含终止回调）结束才算完成，浏览器就一直转圈、侧边栏停在骨架屏。
线上实测：发布后第一个打开订单售后费用明细的人，页面会卡两分钟以上。
改成：页面只返回毫秒级的店铺目录兜底，完整候选（目录 ∪ 订单镜像店铺）由新增的
order-data:warm-shop-candidates 每小时预热一次，并在发布脚本的 cron 里注册。
|
2026-10-07 14:21:36 +08:00 |
|
|
|
916fb30f37
|
修复批量筛选：纯数字单号当数组键会被 PHP 转成 int
batchValues() 原来拿值本身当数组键去重，纯数字订单号（如 3317080368285022883）会被
PHP 转成 int，后续 whereIn 就成了数字和长文本比较，走不上 so_id / outer_oi_id 的
前缀索引，实测退化成全表扫描（70 秒以上）。
改成键加 v 前缀、返回原字符串，ctype_digit 显式传字符串。新增用例覆盖前导零单号
0001234 与 1234，防止再回归。
|
2026-10-07 14:05:53 +08:00 |
|
|
|
e5922dd78e
|
订单售后费用明细 / 商品推广费用明细：订单号和商品编码支持批量查询
两个页签的「订单号」「商品编码」改成多行输入框，可以直接粘一整列：
每行一个，或用逗号、空格、分号、顿号分隔，一次最多 50 个值，多值取并集。
- 订单号批量：先去两套来源解析候选 o_id（单表、等值 IN，走各自前缀索引），
再按订单过滤；单个订单号仍保留「从头匹配」的模糊语义。
线上实测 20 个真实单号解析 0.01 秒。
- 商品编码批量：每个编码在 商品/款式/店铺编码（推广页为 item_id）里匹配一组，
多组 OR；仍受统计日期/订单日期范围约束。
- 非淘系旧查询路径同步支持批量，保持两套口径一致。
|
2026-10-07 13:55:02 +08:00 |
|
|
|
4b97b30a3a
|
商品推广费用明细：店铺筛选改成和订单售后费用明细一致的多选控件
- 把「店铺名称：可点选的多选 + 模糊搜索」抽成公共组件
partials/order-data-shop-picker.blade.php，订单售后费用明细改为引用它，
商品推广费用明细用同一个控件（原来是一个纯文本输入框）。
- 推广页提交 shop_name[]（多个取并集），后端镜像查询和非淘系旧查询都改成
按多个店铺 OR 匹配，仍兼容原来的单个 shop_name。
- 推广表的店铺名带下划线（天猫_卓禾家具旗舰店），和订单镜像的「天猫-…」
不是同一套命名，所以候选单独取自 ops_item_sales_cost_ratio 当前统计日期
出现过的店铺，按日期缓存 24 小时（单次约 0.4 秒、约 400 个店铺）。
|
2026-10-07 13:39:25 +08:00 |
|
|
|
af83d75a00
|
订单售后费用明细：订单号查询改为先解析候选订单再过滤
订单号原来在「订单 ⋈ 明细」关联后做三列 %x% 匹配，没有日期条件时优化器会放弃
索引，淘系那套 520 万订单 × 680 万明细必须全表扫描，线上实测单条跑到 19 分钟
还没结束（还占满 Apache 工作进程）。
改成两段式：先用带前缀索引的单表查询把订单号解析成两套来源各自的候选 o_id
（线上订单号 / 子订单号从头匹配、内部订单号按数值等值），再让分支按 o_id 过滤。
两套来源分开解析，避免两侧 o_id 撞号。候选超过 500 条或订单号不足 4 个字符时
退回原来的包含匹配，保持既有行为。
顺带给 jst_OrderItem 补 outer_oi_id 前缀索引（非淘系子订单号原来要扫 70 秒），
已在生产建好索引。
|
2026-10-07 11:31:56 +08:00 |
|
|
|
cf7924fdc6
|
订单售后费用明细：合并淘系（天猫/淘宝）订单来源
聚水潭把淘系订单放在 jst_qmcust_* 系列；页面镜像已接入后，报表改为两套来源合并：
- 订单、明细、售后分别按来源取数（ops_jst_orders* 与 ops_jst_qmcust_*），列映射一致；
淘系明细没有 send_warehouse，用订单上的 wms_co_id 兜底
- 每套来源各自下推筛选条件并按当前页各取所需行数再合并，避免整表物化后排序
- 店铺候选同时包含两类店铺（天猫-/淘宝- 前缀）
- 镜像数据集登记：jst_qmcust_orderlist/_item、jst_qmcust_refundlist/_item 及分层策略
- 用例：淘系订单与售后进入报表、店铺候选包含淘系、双源多店铺筛选
|
2026-10-07 10:00:20 +08:00 |
|
|
|
eda10bd740
|
订单售后费用明细：店铺筛选改为可点选的多选模糊查询
- 店铺名称由单个输入框改为可点选的多选下拉：候选里可按关键字模糊筛选、多选、全选当前结果/清空
- 提交 shop_name[]，多个店铺取并集逐个模糊匹配；保留旧的单值 shop_name 兼容
- 候选来自订单镜像中真实出现过的店铺，缓存 1 小时；单次最多 50 个店铺，超出在面板内提示
- 补充仓库层与页面层用例
|
2026-10-07 10:00:20 +08:00 |
|
|
|
b66f223ebb
|
修复账单冲减取数和工单加载，整合快递页面上线 (#141)
|
2026-09-09 14:04:43 +08:00 |
|
|
|
be670ad988
|
feat: stage tiered business data storage (#104)
|
2026-09-07 11:55:37 +08:00 |
|
|
|
b1bfbe2400
|
perf: avoid promotion sku map scans
|
2026-09-01 13:23:31 +08:00 |
|
|
|
d62ad27d0f
|
fix: centralize shared business data and remove local sqlite path
|
2026-09-01 11:34:37 +08:00 |
|
