共享 staging 跑完 2000 条用例后，怎么自动化验证「测试数据确实清干净了」？fixture teardown passed ≠ DB 回到基线，有没有 10 秒内的轻量门禁方案？

背景

我维护一条 B 端 SaaS 的接口自动化（Python 3.11 + pytest 7.4 + httpx，约 2000 条用例），跑在 5 人共享的 staging 上（MySQL 8.0 + Redis 7.2，GitLab CI）。每条用例的 fixture teardown 里都有清理逻辑（DELETE / 状态回滚），CI 跑完 pytest 显示全绿。

现象

• 每周 2~3 次，第二天早上第一个跑的人遇到「数据残留」：昨天的用例创建了一个 tenant_id=9999 的测试租户，今天某条 SELECT COUNT(*) 断言就偏了；
• 更隐蔽的：teardown 里 session.delete() 跑了、pytest 报了 passed，但实际 InnoDB 在 REPEATABLE READ 下，事务还没 commit 连接就断了——数据还在；
• 我手动 mysql -e "SELECT COUNT(*) FROM orders WHERE created_by='test_automated'" 查了 3 次，发现残留集中在「多步事务」用例（创建→关联→删除），单步 CRUD 很少残留；
• 最烦的是：残留数据不报错、只让断言偏移，表现为 flaky，排查时先怀疑用例本身，绕了 20 分钟才发现是上一轮没清干净。

已尝试

1. conftest 全局 teardown 加 SQL 校验：session 级 finalizer 里跑 3 张表的 SELECT COUNT(*) WHERE created_by LIKE 'test_%'，超阈值就 pytest.exit(1)。问题：2000 条用例跑完再扫 3 张表，每次多耗 40~60 秒，CI 超时风险大，而且只覆盖了 3 张表、其他 11 张没查；
2. Redis 侧 EXPIRE + MySQL 定时 job：Redis 有 TTL 还行，MySQL 没有原生 TTL，定时 job 又和 CI 时间窗口对不上（CI 跑完到 job 触发之间还有 5~10 分钟窗口，期间有人跑就中招）；
3. 每次 CI 前 DROP + 重建 schema：staging 是 5 人共享的，不能动，pass。

期望得到的答案形态

1. 有没有人在 CI 里加过「跑完后的基线校验门禁」？ 具体怎么做的？（SQL 快照对比？行数校验？binlog diff？checksum？）最好能给个可复现的 CI job 片段或脚本；
2. 怎么在 2000 条用例规模下把校验耗时控制在 10 秒以内？ 只校验增量表？用 information_schema 对比？用 binlog 解析只查「本轮 INSERT 过的行」？
3. 「teardown passed 但数据实际没删干净」这种 InnoDB 事务边界问题，你们有没有遇到过？怎么在 fixture 层面保证 commit 真正落盘？（显式 session.commit() + connection.ping()？还是别的路子？）
4. 有没有比「全表 COUNT」更轻量、更通用的方案？比如一个通用的「测试数据标记 + 批量校验」框架？

参考：站内已有讨论《共享测试环境里"谁污染了谁的数据"》（id=1449）侧重运行时的隔离策略（物理库/逻辑租户/重建），我这个问题侧重跑完之后的验证门禁——两者互补但角度不同。