yufpga

恭喜恭喜

已领取 感谢

我之前用的支付宝周期扣款，没那么多限制

op 引用的链接说的很清楚, 在于过滤的时机在生成临时表前还是生成临时表后。那么在某些情况下， 使用 on 能够极大的减小临时表的大小. 临时表太大，如果数据库服务器磁盘，内存等资源不充裕时，就会导致 sql 执行失败(我曾经在 mysql5.6 上出现过这个问题, 后来改用 on 就可以了).

指法不一定百分百标准，每个人习惯不一样, 能做到字母和一部分功能键盲打即可. 但对于一部分盯着键盘打字，连自己输入错误都不能及时发现的人来说, 我觉得练习指法还是有必要的. 因为可以减少 bug 和变量名拼写错误的情况.

这让我想起来去年这个时候用 python 写过一个:
https://gitee.com/fpgayu/national-day-avatar

官方文档:
https://gorm.io/docs/dbresolver.html

@firejoke 是我看差了, 我以为只有一个 queue, 而你的代码里是两个 context, 各自 3 个 queue, 也就是总共 6 个 queue, 对应 6 个 write_db 的 task. 当遇到 await 的时候, 确实是会跳转到别的 task 里面执行. 确实比较奇怪，但我仍然觉得瓶颈不大可能在 parse_text, 你可以试着记录一下队列写入数据的速率， 如果这个速率也在 400/s 左右, 那说明确实有可能是 parse_text 慢了

大概看了下, 这瓶颈显然不是在 parse_text 中的文件读,就算再怎么阻塞，读写本地文件也不至于到每秒才 400 行的程度. 而在 write_db 中, 出现好几处 await 的地方, 这些地方可都是要同步等待结果返回的呀. 一个很好容易验证的方法就是把 write_db 中的 await 用 await asyncio.sleep 替换掉, 尝试不同的 sleep 时间. 实际上上面的问题在于每一次 while 1 的循环循环是同步的, 你必须要先处理完队列中的前一条数据, 才能继续处理下一条数据. 所以处理也很简单, 把每一次的循环异步化掉.