yml2213
92d7887108
perf(db): 运营态计数/统计加覆盖索引，消除 248MB/次的全表扫
pg_stat_statements 重置后 25 分钟窗口显示，work_orders 相关查询里每次调用读取量最大的
全是"按运营态筛选"的形状：
SELECT COUNT(*) FROM work_orders wo LEFT JOIN (<拼单汇总>) WHERE <运营态 CASE>
87 次调用、每次约 248MB、均 347ms
筛选统计的同形查询多次，248~545MB/次
根因：运营态不是存储列而是算出来的 CASE（依赖 status/sharing_enabled/sharing_total_quantity
+ 拼单汇总），规划器只能逐行求值，EXPLAIN 显示 "Rows Removed by Filter: 95923" ——
把 9.6 万行、约 533MB 的宽表整张读出来再丢掉。
迁移 085 给 CASE 用到的三列建覆盖索引（约 4MB，堆表的 1/130）：
同一查询实测 248MB → 22MB、184ms → 75ms（IO 降 11 倍）。
status 本来就有索引、状态流转本来也走不了 HOT 更新，故不额外增加写放大。
验证：后端 533 项单测全绿（新增 1 项守卫）；生产真机 EXPLAIN (ANALYZE, BUFFERS) 前后对比。