你说的这个是 P1 级的产品 BUG，你确定是设置私有仓库后被别人 fork 了吗？

私有仓库被别人怎么 fork ？看不到啊

有钱一起赚可行？

也用 go，给个 star ！

看到了，网站现在只是一个雏形哈，那你打算怎么召集人来开发呢，还是自己独立开发出来这个东西？

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 结果贴一下

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

没有贷款？