用 git rebase 当前分支，可以将多个提交合并成一个提交，这样就不会有大量的「小提交」了。

@qichengzx 通常只有分布式系统（如分布式数据库）才需要用到全局唯一 id，如果是初期的项目，往往根本不需要用分布式系统，根本不存在你这个系统的使用场景啊。

权力的游戏。只看了 20%

list 在 C 实现中的数据结构是一个 PyObject*类型的数组，不具备链表的特性。
楼主应使用 deque，是一个双向链表的实现。

连续 3-4 年 1 点以后睡觉的我感觉好慌 = =

18 楼... 服气了

自己写规则转

lang 应该是 language 的缩写吧

HR 的新套路？

网上抓的免费代理可用率和速度都感人... 不管是公司的活还是自用我都愿意花钱买，至少质量比免费的高不止一档了。

无备份？这心也太大了吧。无备份的话除非从第一条数据进入到现在的 binlog 全部保留了，否则凉凉...

GraphQL

mark

我会先看，过后会专找时间重过一遍做笔记

可以工单申请换 IP 的

厉害了

@monsterj 第三种。第二种方法会发送大量 SQL，造成 N+1 问题。
我不明白你所说的「 in()里的数据多了影响性能」是否有论据。使用 in 也是可以命中索引的，性能并不会比 join 差多少。

让数据库做行遍历少的 join 是可以的，尤其是能做到小表驱动时。剩余的情况更倾向于单表多次查询。
像 GraphQL 这类查询语言，其原生版本就不支持多表的 join 查询。即使 join-monster 这样的中间件，其底层实现 join 的技术也有两种。其官方文档里也明确在一对一级联（或少量数据级联）的情况下可使用 join 查询，而在多对多级联则建议使用单表 batch 查询。
如果你们的数据库在后期会做水平分库的话，不管是使用 proxy 还是数据库中间件，对 join 查询的支持都不好（分布式数据库对 join 查询是很不友好的）。所以如果前期尽量避免 join 的使用的话会省很多事情。
另外，单表多次查询可以对查询的中间结果缓存，这对 join 来说是很难做到的。