b 站也关注了，不过这么快就有方案和网站出来了吗，执行力很强啊

有，太多了，楼上加 10086

维护中

Fantastic!

666666

国企现状，这其实是你的选择

@encro [环境：mysql 5.7.29 ，测试机远程连接云主机上的 db]
反复测试后的结果显示，IN 后面跟超过 1 个元素就不会走任何索引，加上 order by id 才走了主键索引，走主键索引比加上 force index(idx_city_id)要快很多，后者 explain 的结果显示走的 idx_city_id 索引，rows 为表总行数的两倍(why?)。另外加了 delete_time is null 也是会走主键索引，记得加上 limit 。
（我分别把测试表中的 delete_time is null 行数调整为 0/10w/all，与楼主同样的 SQL+limit 10000 都只需要 0.Xs ，楼主执行的 SQL 是不含 limit 的吗？如果不含 limit，我这里的执行时间超 1min，不可能在生产环境不加 limit 吧。）

@Leigg 是的

```
CREATE TABLE IF NOT EXISTS million_user_info (
id bigint(7) PRIMARY KEY AUTO_INCREMENT,
city_id int,
delete_time TIMESTAMP,
others VARCHAR(111) DEFAULT "" NOT NULL
);
CREATE INDEX idx_city_id ON million_user_info (city_id,id);（无独立 city_id 索引）
```
模拟环境：
125 万条数据；插入的 city_id 在楼主给出的 city_id 范围内，others 为干扰随机 str
查询语句：
```
SELECT * FROM `million_user_info` WHERE ( `city_id` IN (45757,45967,46044,46126,46288,46473,46642,46769,46919,47078,47119,45758,45762,45786,45811,45822,45839,45850,45870,45877,45892,45905) ) AND `million_user_info`.`delete_time` IS NULL ORDER BY `id` DESC LIMIT 1000;
```
测试结果：
当 delete_time=null 的行数实际只有 1 行时，秒查；
当 delete_time=null 的行数实际有 10w 行时，且 SQL 无 limit，耗费 11s ；
当 delete_time=null 的行数实际有 10w 行时，且 SQL 加 limit 1000，秒查；
当 delete_time=null 的行数实际有 10w 行时，且 SQL 包含 force index，无 limit，耗费 15.9s ；
当 delete_time=null 的行数实际有 10w 行时，且 SQL 包含 force index，加 limit 1000，耗费 4.9s ；
加上单独的 city_id 索引后，上述测试结果无明显变化。

可以把 `show create table user_info` 和 explain 结果贴一下

对于技术书籍，读之前要求自己一定要有输出，博客 /笔记都可以，否则真的读完翻篇就忘。

没有贷款？

可能是深坑 不建议

以下说明含有优先级：
1. 她此刻需要有人安慰，排解，可以带出去散散心，玩点运动释放一下
2. 需要让她接受职场就是这样，不论在哪里都不可能避免完全没有上司欺压、同事排挤， 公司恶心，在职场工作就意味着要学会接受，容忍，风雨过后见彩虹，经过了这些才会成长。
3. 如果尝试之后或者现在根据你对她的认知认为她可能承受不了这些（会抑郁），那么请果断让她辞职，生之为人，健康与快乐永远排第一，其余皆是身外之物。

2 的想法太简单了。如果用了商业代理，你只能认为代理池 IP 是无限的。反爬要从技术上来解决，可以参考商标网，如果没条件请专门的反爬工程师，那就自己去学习爬取途径再研究反爬措施。

如何证明漂亮？

骑驴找马是可以的，不要裸辞。

早跳槽一年短期看是多赚了一点工资，长期看是大亏。