如果是的话，那就可以解释了。

查询优化器可能将 select b.* from b_city b where b.nodeid in (select a.nodeid from b_city a)转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.nodeid = b.nodeid)，然后又转化为 select b.* from b_city b where
exists(select 1 from b_city a where a.id = b.id)，它的执行可以做到跟展示的执行计划匹配，可以逻辑地理解为“检查 b_city 的每一行，对于每一行，查询是否存在 id 为这行 id 的 b_city”。

至于为什么不限执行 select a.nodeid from b_city a，不管是怎样，你都要检查 b_city b 的每一行，相比于检查 b_city b 的每一行的 nodeid 是否存在于 select a.nodeid from b_city a 所代表的集合中，为什么不直接检查 b_city a 中是否存在 nodeid 为 b_city b 行 nodeid 的行呢？如果 nodeid 索引是唯一索引并且 nodeid 是 not null 的话，它甚至可以做到“检查 b_city b 的每一行，检查 b_city a 中是否存在 id 为 b_city b 行 id 的行”。

nodeid 索引是唯一索引并且 nodeid 是 not null 。对吗？

@kimqcn #55 “是不是 IS NULL=全表扫描”，可以看一下这个相关讨论 https://www.sunp.eu.org/t/694500 。

最近在看《数据密集型应用系统设计》，如果对你现在的情况合理的话，或许你应该分开 OLTP 和 OLAP 。

@zzhpeng #26

我主要是表达“条件为 is_virtual = 0，并且大多数的 is_virtual 都是 0”的时候，idx_storeid_isvirtual 其实是没有什么用处的。

你那条语句是直接在同一个环境运行的吗？如果是的话，单独运行肯定跟同其他语句并发运行是不一样的，我不清楚具体的情况，无法给你答案。

@GTim #18 你理解错了，具体情况具体分析吧。

1. 你说“如果没有聚合函数，select 是在 order by -> limit 后面执行的”，此问题的例子就能够说明这种说法是错的。
2. 你说“但是有了聚合函数，select 会优于 order by -> limit 执行”，假设 SQL 是 select sum(c1) from t group by c2 order by c2，如果先执行 select sum(c1)，之后的 order by c2 怎么能够成功呢？

@zzhpeng #21 所以你的索引基本没什么用，甚至会降低速度，因为对于每个符合条件的 secondary index 子节点，都会去 clustered index 搜索。

如果有人好奇“为什么加了 LIMIT 1，COUNT(*)还可以正常工作的话”，可以看一下 https://stackoverflow.com/questions/17020842/mysql-count-with-limit 。

sima_order.is_virtual 是不是只有 0 和 1 两种值？每个值对应的行数是多少？

我觉得你的 SQL 语句不太合理。

1. 为什么 LIMIT 1 和 COUNT(*)一起使用？
2. 为什么使用了 COUNT(*)，还要进行无谓的 ORDER BY ？

想了解一下大家都是使用什么？不用简书的话

@gfreezy 我好像明白了。sign 代表是不是还要考虑接下来的字节。union branch 1 (long, not null)代表类型是 long，因为 branch 0 是 null，所以 long 是 branch 1 。但是我不太确定自己的理解是否正确。明天再仔细看看。

@iConnect #3 虽然 https://dev.mysql.com/doc/refman/8.0/en/is-null-optimization.html 说了“MySQL can perform the same optimization on col_name IS NULL that it can use for col_name = constant_value. For example, MySQL can use indexes and ranges to search for NULL with IS NULL.”，但是我更想知道“索引是怎么存储 null”的官方文档，可惜我没有找到。

@yyyyfan #1 有没有官方文档说明这个东西呢？我并没有找到相关的内容。

@liprais #6

我看完了 https://redis.io/topics/distlock，https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html，http://antirez.com/news/101 。

我个人挺认可 Redis 作者所说的“Most of the times when you need a distributed lock system that can guarantee mutual exclusivity, when this property is violated you already lost.”。如果方便的话，可以分享一下你的想法吗？谢谢。

@wakzz #12 我不太认可你所说的“避免死锁”，因为根本都不会出现死锁这种情况。关于 ttl，所有实例里的同一个 key 的 ttl 都一样。https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock 有讲到延长 ttl，但是它也强调了“so the maximum number of lock reacquisition attempts should be limited, otherwise one of the liveness properties is violated”。所以不是“不断给未释放的锁续期”，而是 client 还未完成计算，但是失效时间快要到了，client 可以请求延长时间。就算是这样，也不是“直到锁释放”，延长是有次数限制的，不然就会违反活跃性这个特性。

@ALLLi #1 其实我感觉，你并没有太明白我的问题，而且也没有回答到我的问题。

@ALLLi #8 是的，https://redis.io/topics/distlock#is-the-algorithm-asynchronous 中也说了“At this point we need to better specify our mutual exclusion rule: it is guaranteed only as long as the client holding the lock will terminate its work within the lock validity time (as obtained in step 3), minus some time (just a few milliseconds in order to compensate for clock drift between processes).”。

@AmmeLid #7

我觉得并不是，维基百科说“A livelock is similar to a deadlock, except that the states of the processes involved in the livelock constantly change with regard to one another, none progressing.”。

但是就我们这个例子，比如一个实例下线了，只剩下 4 个，client1 获取到两个，client2 获取到另外两个，它们都无法成功获取到锁，之后释放，但是 https://redis.io/topics/distlock#retry-on-failure 中说了“When a client is unable to acquire the lock, it should try again after a random delay in order to try to desynchronize multiple clients trying to acquire the lock for the same resource at the same time (this may result in a split brain condition where nobody wins).”，因为随机的延迟，最后不会出现“none progressing”这种情况。