但是你这样写，每次查 DB 都要扫全表做正则匹配吧...数据量大一点性能应该很捉鸡

用布隆过滤器应该可以搞得比较快。
新增一个用户-布隆的 bitmap 表，主键用户 id，另一列一个大 bitmap
然后
select *
from 问题表
where
!( 取布隆 bit 结果(问题 id) & 用户 bitmap)
# 假定 id 连续单调递增
order by 问题 id
offset 页数*页大小

没有具体 benchmark，不过我想这大概能用，线性遍历问题表够了就可以返回的算法

不过其实算一下，9,000,000 条问题，一条算 1KB，内存占用也就 9GB 这个数量级，如果业务允许（例如增删改不不频繁），我会搞两台内存大的服务器，直接在内存里面玩上面的解法；
如果“用户回答超过 10w”指的是一个用户的话，那就改成随机从问题库里面挑然后位与康康有没有回答过，分页按钮改成“换一批问题”（不然每次都要遍历 10w 个问题）
一定要分页的话，可以给用户记录一个“上一次回答的最后一个问题的 id”，下次找的时候从那个 id 开始找。

可以了解下 Apache 的 druid，这种场景很适合

@Livid spam ？

如果 func_A 或 B 内涉及外部 IO 例如网络等，这俩并行的话还是可以提高那么一丢丢性能的，不过在这个 case 里面个人更倾向于优化 func_A 和 func_B 的性能为主，可以先做下 benchmark 看看瓶颈在哪

@Macuilxochitl 对我就是深大南头这边，没有 wifi 基本就与世隔绝

啊这
一眼就认出是发穿山甲招聘的那位
起码目的达到了，不是吗

牛逼吹得比谁都大
预算给得比谁都少
就差程序员

要不换成 SSD ？如果是自己的物理服务器，可以搞 nvme 的，或者组个 raid，应该会更快
等等首先现在你的瓶颈在哪里...是定位到了线程池里面大部分线程都在等 os.remove 吗(个人感觉应该是读文件的成本远远高于删文件吧）
如果不是的话...不要提前优化

我想到的这些：
1. 如果业务上面可以实现的话，在请求到的时候再生成文件，不落硬盘直接发送
2. 按照文件名之类的唯一键，hash 到多台服务器上面处理
3. 只能单机的话，可以调研一下有没有适合这个场景的文件系统...

感觉好像用布隆过滤器可以搞定？

@makdon 建一个新库表，从旧表读所有数据，用 map reduce 去重，写去新表。需要考虑去重期间新写入的数据的临时存放。

感觉这个需求用 map reduce 还是很好做的

看见第一点就知道不是培训班就是公众号，直接拉到最底果然

Python 的官方中文文档是由社区维护的，由大家自发参与贡献自己业余时间翻译的，不是由中文水平不知道高到哪里去专业翻译人员参与，因此不能强求每个人都有很高的水平，翻译都可以做到信达雅；而且若要翻译质量高的话，花在遣词造句的时间更多，同样时间投入产出条数更少，因此极高质量翻译占比不高也是正常的。
其次，目前应该是还没有复核员对词条的翻译进行审核的，只是靠社区发现问题并修正。
不过用机翻贡献词条可能并不是一个值得提倡的做法，如果你发现某个词条有误，可以在 python/python-docs-zh-cn 这个仓库提 issue，或者直接申请成为翻译组一员修改错误的翻译。

附 git repo：
https://github.com/python/python-docs-zh-cn

步行上班,,,

静态的项目使用 gitlab pineline 就可以了 8 ？