@CNife 感谢回复，但是觉得他的回答很重呢--

这个问题就要深入了解 go 的两级线程调度模型了，简单来说 go 是自己的 runtime 中实现了用户线程和系统线程的相互转换调度的过程，其他大部分语言的用户线程基本都是直接 1:1 系统线程，线程调度交给了内核，而 go 的用户线程与内核线程的配比是 M:N，go 在这两种线程之间的转换调度做了不少工作，正式这个做了这个优化才使得 go 的用户线程相比于其他语言的用户线程而言是十分轻量的。

@oschina 他说的是他看到了对方的私有仓库，所以我建议他把地址贴出来给大家看看，这没毛病把

@coderabbit 你的密码改了吧，把对方的仓库地址贴一下

应该是 P0 级

你说的这个是 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 吧。）