# MCP MQL 翻页重复数据陷阱（2026-07-31 实测）

## 症状
`search_by_mql` 用 `session_id` + `group_pagination_list` 翻页时，page 2 可能返回与 page 1 **完全相同的数据**。

## 实测案例
- 查询 `销售管理.活动` WHERE `start_time = '2026-07-27'` ORDER BY `start_time` DESC
- 返回 `count: 89`，实际应为 89 条 → page 1 返回 50 条
- 用 `session_id` + `page_num=2` 翻页，返回数据与 page 1 完全一致（同 50 条）
- **结果：丢失 39 条数据（89 - 50 = 39）**

## 检测方法
翻页后对比 page 2 第一条的 `work_item_id` 与 page 1 第一条是否相同：

```python
first_id = page1_items[0]['work_item_id']
if page2_items and page2_items[0]['work_item_id'] == first_id:
    print('PAGINATION DUPLICATE — using page 1 only')
```

## 应对策略
1. **count ≤ 50**：数据完整，无需翻页
2. **count > 50**：翻页验证 → 若重复则接受 page 1 的 50 条
3. 简报中标注"活动X条（翻页限制，实际可能更多）"
4. 大量数据（>500 条）必须用 curl JSON-RPC 直连而非 tool_call 翻页

## 与 LIMIT OFFSET 的对比
MQL 的 `LIMIT 50 OFFSET 50` 模式（在 curl JSON-RPC 中）翻页正常，但 `tool_call` 通过 `session_id` + `group_pagination_list` 翻页时出现此 bug。curl 直连时可使用 OFFSET 翻页规避此问题。

## 影响范围
- 依赖 `search_by_mql` 翻页的场景
- 单日活动查询（50-89 条）：丢失 ~40%
- 已确认：2026-07-31 cron 执行中触发