在 EBS INV 里谈“逻辑对象瓶颈”，要分两层看：事务写入链路（过账慢/卡死） 和 查询链路（Workbench/报表/ATP 慢）。下面按“哪个逻辑对象在哪种场景下成为瓶颈 + 为什么 + 典型症状”列，都是生产环境真实踩坑点。
一、事务写入链路：最容易导致“库存不动”的瓶颈
1. INV Transaction Manager / Worker（INCTCM + INCTCW）
- 逻辑对象：INCTCM（轮询调度）+ INCTCW（Inventory Transaction Worker）+ 底层 INV_TXN_MANAGER_PUB
- 瓶颈本质：单管理器串行轮询 + Worker 并发度不够；接口表里几万行没消费，前端所有出入库都“Pending”。
- 典型症状：
- MTL_TRANSACTIONS_INTERFACE 中 PROCESS_FLAG=1, LOCK_FLAG=2, TRANSACTION_MODE=3 堆积几万~几十万行
- SO 发货/PO 收货界面显示“已提交但未过账”
- Worker 进程 defunct，并发管理器 actual=0 target=10
- 放大因素：一批接口里带 15 万行 MTL_SERIAL_NUMBERS_INTERFACE，Worker 逐行校验直接小时级
2. MTL_TRANSACTIONS_INTERFACE / MTL_MATERIAL_TRANSACTIONS_TEMP（接口态逻辑表）
- 逻辑角色：开放接口 → 待处理临时表，TM 的唯一消费源
- 瓶颈本质：不是表本身慢，而是它成了锁竞争和长事务载体
- LOCK_FLAG 行级锁被 Worker 持有不放（异常中断后不释放）
- 大批量外系统（MES/WMS）直灌，未分批，单次 commit 几十万行
- 与 MTL_SERIAL_NUMBERS_INTERFACE、MTL_TRANSACTION_LOTS_INTERFACE 三表联动膨胀
- 经验值：单组织单日接口行 > 50 万且不分批，TM 必抖
3. INV_QUANTITY_TREE_PUB（可用量树）
- 逻辑对象：内存+DB 混合的“数量树”，Pick Release / 预留 / 发料前必调
- 瓶颈本质：按 Item+Org 加锁，高并发发同一物料时串行化
- 典型场景：
- 大批量 Pick Release 同一热销料 → 大量 session 等 INV: Quantity Tree Timeout for Lock
- 树锁超时（profile 控制）后报错而不是继续，看起来像“随机失败”
- 这是 INV 里最典型的“逻辑锁瓶颈”而非 SQL 慢
4. INV_TXN_MANAGER_PUB 内部校验链
过账时同步跑：
- 物料状态校验（MTL_ITEM_STATUS）
- 批次/序列号校验（MTL_LOT_NUMBERS / MTL_SERIAL_NUMBERS）
- 子库/货位有效性
- 负库存/ATP 检查
- 抛成本（CST_*）与 GL 预检
其中 批次+序列号同时启用 时，单行事务逻辑开销可放大 10~100 倍（15 万序列号行附带一个 MTI 头就是经典案例）。
二、查询链路：最容易导致“画面转圈”的瓶颈
5. MTL_MATERIAL_TRANSACTIONS（MMT）
- 逻辑角色：全量事务流水，成本/追溯/报表都来扫
- 瓶颈本质：亿级大表 + 统计信息过期 + 无分区/无日期裁剪
- Material Workbench 查全组织 → 走全表扫 MMT
- 自定义报表 WHERE inventory_item_id=:x（缺 transaction_date 谓词）无法分区裁剪
- MOS 明确：MMT 过大是 CST/INV 报表慢的头号原因，首选 Gather Stats + 按 TRANSACTION_DATE 分区
6. MTL_ONHAND_QUANTITIES + INV_QTY_TREE 查询
- 逻辑角色：现有量汇总（非流水）
- 瓶颈本质：
- 货位/批次/状态维度全开 → 行级爆炸
- Material Workbench “View by Location + Detailed” → 触发 UPDATE MTL_MWB_GTMP 然后逐行 INV_PROJECT.GET_LOCATOR 和 MTL_ITEM_LOCATIONS 单点查询，全组织查可挂几小时
- 这是“查询逻辑对象”里最容易被误认为 DB 慢、实际是 Form 逻辑 N+1 查询的例子
7. INV Reservation 逻辑（MTL_RESERVATIONS + 需求供应匹配）
- 瓶颈：预留量重算 + ATP 调用
- Item Supply/Demand 窗体（INVDVDSD）在 MTL_TXN_REQUEST_LINES 有 600 万历史行未归档时，远程调用 5 分钟超时（APP-INV-05647/5649）
- 根因不是 Reservation 表本身，而是移动单历史行未清理导致 supply/demand 展开过大
8. Move Order 逻辑（MTL_TXN_REQUEST_HEADERS/LINES）
- 分配（Allocate）时写 MTL_MATERIAL_TRANSACTIONS_TEMP，再等 TM 消费
- 大移动单（几万行）+ 同时 Pick Release → 与 Qty Tree 锁、TM Worker 抢资源三角死锁
- INV: Pick Slip Batch Size 设太大 → 单 commit 撑爆回滚段
三、按“瓶颈类型”归纳（便于你排错时定位）
|
串行消费瓶颈 |
INCTCM/INCTCW、MTI/MMTT |
接口堆积、外系统灌量 |
|
逻辑锁瓶颈 |
INV_QUANTITY_TREE_PUB |
热料高并发发料/Pick |
|
大表扫描瓶颈 |
MTL_MATERIAL_TRANSACTIONS |
报表/Workbench 无日期裁剪 |
|
N+1 查询瓶颈 |
Material Workbench + MTL_MWB_GTMP + GET_LOCATOR |
全组织按货位明细查 |
|
历史数据膨胀 |
MTL_TXN_REQUEST_LINES、MTL_SERIAL_NUMBERS_INTERFACE |
Supply/Demand、接口重算 |
|
跨模块级联 |
INV_TXN_MANAGER → CST_ 成本 → WSH/OM 回调 |
成本管理器掉队连带 INV 卡 |
四、一句话结论（生产优先级）
- “库存卡住不过账” → 先看 INCTCW 是否活、MTI 是否堆、Qty Tree 是否锁，90% 在这三个逻辑对象。
- “画面/报表慢” → 先看是不是扫了 MMT 全表、Workbench 是否开了 Detailed+Locator、移动单历史是否清过。
- INV 的性能瓶颈很少是某个物理表缺索引这么简单，更多是 TM 消费模型 + Qty Tree 锁模型 + Form 的 N+1 逻辑调用 三者叠加。
