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 来说是很难做到的。

笛卡尔积，MySQL 的 Nested Loop Join 了解一下

@alian 有 api ？还是爬的页面

数据从哪来的？

就算一位数是一个字节，也能表示 256 种 ASCII 码，三位随机数的空间已经达到 2^24 了。

@iblislsy 玩短线？如何判断走势？