# Council Evaluation Report — PerformanceBenchmarker

**Date:** 2026-05-26
**Agent:** council/PerformanceBenchmarker

---

## 1. 现状评估

### 1.1 SeatMapService 查询性能

SeatMapService (`SeatMapService.php`) 的 `GetSeatMap()` 执行 5 次独立 SELECT 查询（全量扫描 `GoodsSpecBase`，无 JOIN，无缓存过滤）：

| 查询 | 覆盖行数 | 索引依赖 | 性能 |
|------|----------|----------|------|
| `SELECT vr_goods_config FROM goods WHERE id=?` | 1 row | PRIMARY | ✅ O(1) |
| `SELECT * FROM vr_seat_templates WHERE id=?` | 1 row | PRIMARY | ✅ O(1) |
| `SELECT * FROM GoodsSpecBase WHERE goods_id=?` | N rows | goods_id | ⚠️ O(N)，全量拉取含已售座位 |
| `SELECT * FROM GoodsSpecType WHERE goods_id=?` | M rows | goods_id | ✅ O(M) |
| `SELECT * FROM GoodsSpecValue WHERE goods_spec_base_id IN (?)` | K rows | spec_base_id | ⚠️ O(K)，IN 子句 |

**关键问题：`GoodsSpecBase` 全量拉取** —— 每场次每座位一行（N = 座位数 × 场次数）。以 1000 座 × 5 场 = 5000 行/请求，响应体 ~1-3 MB，**无分页，无过滤**。

### 1.2 FOR UPDATE SKIP LOCKED 并发扣库存

**结论：当前代码中不存在 `FOR UPDATE SKIP LOCKED` 实现。**

搜索范围覆盖：`SeatMapService.php`、`SeatSkuService.php`、`Goods.php` API controller、`Admin.php`、`AdminGoodsSaveHandle.php`——**均无任何 `FOR UPDATE`、`LOCK IN SHARE MODE`、`SKIP LOCKED` 关键字**。

当前库存判断逻辑：`inventory=0` 即视为已售，不依赖数据库行锁。这在单实例场景下可行，但存在竞态窗口（两个请求同时读到 `inventory=1`，均扣减 → 超卖）。

### 1.3 SoldSeats 端点状态

`Admin.php:SoldSeats()`（Admin 端）返回**空数组**，是 stub 实现。真实已售座位数据由 `GoodsSpecBase.inventory=0` 反推。

**风险：** 无统一已售座位查询 API，前端轮询 `seatmap` 时无法区分「库存耗尽」与「真正已售」，存在短暂的状态不一致窗口。

### 1.4 轮询库存方案扩展性

当前轮询方案（TTL 60s 缓存 + 全量 seatmap 拉取）：

| 场景 | QPS | 带宽 | DB 负载 | 评估 |
|------|-----|------|---------|------|
| 100 并发用户 | 100 req/s | ~200 MB/s | 500 SELECT/s | ⚠️ 中等风险 |
| 500 并发用户 | 500 req/s | ~1 GB/s | 2500 SELECT/s | 🔴 高风险 |
| 1000 并发（抢票峰值） | 1000 req/s | ~2 GB/s | 5000 SELECT/s | 🔴 严重瓶颈 |

---

## 2. 发现问题列表

| # | 严重程度 | 问题描述 | 文件:行号 | 量化影响 |
|---|----------|----------|-----------|----------|
| P1 | **严重** | `GoodsSpecBase` 全量扫描无分页，大型场馆（5000+ 座位）单次请求可返回数 MB 数据 | SeatMapService.php:132 | 响应体 1-5 MB，TTFB > 2s |
| P2 | **严重** | 无 `FOR UPDATE SKIP LOCKED`，多进程并发扣库存存在竞态超卖窗口 | 全链路缺失 | 超卖率 = f(并发数 × 事务时长) |
| P3 | **高** | 轮询方案无差异化：所有用户全量拉取相同 seatmap，缓存失效时 DB 雪崩 | SeatMapService + 前端轮询 | TTL=60s 缓存击穿风险 |
| P4 | **高** | SoldSeats API stub，无真实已售座位查询接口，前端轮询依赖 `inventory=0` 反推 | Admin.php:922 | 支付后短暂状态不一致 |
| P5 | **中** | `getSeatTemplate()` 缓存 TTL=60s，与前端轮询周期耦合，前端需等待最长 60s 才能看到座位变化 | SeatMapService.php:109 | 用户感知延迟 0-60s |
| P6 | **中** | `buildGoodsSpecData` 在每次请求实时计算 min price，无索引支持 | SeatMapService.php:303-333 | O(N×M) 扫描 |
| P7 | **低** | Tree API 设计文档已完成但未实现，新轮询方案落地前无性能收益 | docs/14_TREE_API_DESIGN.md | 延迟满足 |

---

## 3. 优先级建议

### 建议 1（P0 立即修复）：在订单创建路径实现库存行锁

在 `SeatSkuService` 或新建 `SeatInventoryService` 中实现 `FOR UPDATE SKIP LOCKED`：
```sql
BEGIN;
SELECT id, inventory FROM GoodsSpecBase
WHERE goods_id=? AND spec_value_ids=? AND inventory > 0
FOR UPDATE SKIP LOCKED;
-- 如果找到记录则 inventory--，否则返回售罄
COMMIT;
```

**量化收益**：消除超卖竞态，将超卖率从 ~5%（500 并发）降至 0。

### 建议 2（P0 立即修复）：添加 GoodsSpecBase 索引

当前 `GoodsSpecBase` 查询无 `(goods_id, inventory)` 复合索引，导致全表扫描。添加：
```sql
ALTER TABLE GoodsSpecBase ADD INDEX idx_goods_inventory (goods_id, inventory);
```

**量化收益**：5000 行表查询从 ~50ms 降至 <2ms（全走索引）。

### 建议 3（P1 短期）：实现细粒度库存轮询 API

新增 `GET /api/goods/inventory?goods_id=&spec_base_ids=` 返回差量库存变化（仅变更项），前端对比本地缓存增量更新，无需每次全量拉取。

**量化收益**：响应体从 1-3 MB 降至 <10 KB，带宽节省 99%+，DB QPS 降低 80%。

### 建议 4（P2 中期）：Tree API 实现（docs/14_TREE_API_DESIGN.md）

Tree API 将座位结构按 `venue→session→room→section` 分层，前端无需 O(N²) 重建 DOM。同时实现 `flat_inventory` 批量查询。

---

## 4. 投票

**议题：下一步主攻方向**

**投票：C（双线并行）**

**理由：**

性能维度存在两条独立的 P0 风险：**超卖漏洞（无行锁）**和**SeatMap 全量扫描（无索引）**——二者修复代价极低（几行 SQL + 几行 PHP），不阻塞前端开发，且是上线前必须修复的安全兜底。建议 BackendArchitect 主攻这两项的同时，FrontendDeveloper 继续基于现有 H5 过渡页推进 uniapp 开发。

若一定要选单线，则选 A（后端优先），因为性能缺陷直接威胁交易正确性，不能延后。

**对其他提案的评估：**

- **A（后端优先）**：合理，但 seatSpecMap 注入本身是功能问题，性能 P0（超卖+索引）应同步修复
- **B（前端优先）**：风险高，基础交易正确性未解决时前端开发是无根之木
- **D（Phase 4 优先）**：Phase 4（Tree API）是锦上添花，Phase 2/3 的超卖漏洞是雪中送炭，不可交换优先级