接口自动化用例依赖造数，并发跑回归时互相踩脏数据怎么治？

背景：我负责一套 B 端 SaaS 的接口自动化（Python + requests + pytest，约 400 条用例），数据层是 MySQL。用例普遍是「造数 → 调接口 → 断言」的三段式，造数靠直接调内部 admin 接口或写库脚本。

现象：单跑全绿，CI 上用 pytest-xdist 并发（-n 8）跑回归时，大约有 5% 的用例会随机失败，典型报错是「订单不存在」「库存不足」「断言的列表长度对不上」。手动重跑又全绿。基本可以确定是并发用例之间共享了同一批测试账号 / 同一张表的数据，互相覆盖了——比如 A 用例刚造了一个订单，B 用例把同一个账号的订单状态推进了，A 的断言就崩了。

已尝试的排查：

1. 每个用例改用独立测试账号（造数时随机生成 userId）——治好了「订单不存在」类，但「列表长度断言」类还在挂，因为有些页面是全局维度（如公告、字典表），所有用例共享；
2. 把断言从「列表 length == N」改成「断言包含我刚造的那条」——好一些，但还是有偶发；
3. 想上事务回滚（每个用例包一个 transaction，结束 rollback）——但接口是走 HTTP 的，服务侧自己管理事务，测试侧根本拿不到连接，这条路走不通；
4. 考虑给每个 worker 单独一套数据库 schema 或用 --forked 每用例一个进程，但感觉要么成本太高、要么没解决共享字典表的问题。

期望得到的答案形态：

• 你们团队在接口自动化并发回归时，测试数据隔离具体是怎么做的？是按 worker 分库 / 分 schema / 分租户，还是纯靠「独立 userId + 只断言自己造的记录」这套约定？
• 对于全局共享维度（字典、公告、配置类接口），你们是怎么避免用例互相污染的？有没有「只读维度走快照 / 写维度走隔离」这种分层思路？
• 有没有踩过「隔离做得太细导致造数成本爆炸」的坑？阈值大概在哪？

欢迎带具体配置（xdist worker 数、分库方案、造数脚本结构）来聊，越具体越好。