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”这种情况。

@hdbzsgm #2 我不确定我是否正确理解你所说的，你所说的是[Distributed locks with Redis – Redis - Is the algorithm asynchronous?]( https://redis.io/topics/distlock#is-the-algorithm-asynchronous)中所说的“The algorithm relies on the assumption that while there is no synchronized clock across the processes, still the local time in every process flows approximately at the same rate, with an error which is small compared to the auto-release time of the lock. This assumption closely resembles a real-world computer: every computer has a local clock and we can usually rely on different computers to have a clock drift which is small.”吗？算法依赖于每个进程内的时间的流动速度是差不多一样的。是吗？

@jybox #1 你说“同时获取可能会死锁（每个客户端成功在一半的实例加锁），所有客户端都顺序访问就不会出现死锁了”。我不太同意你的说法，比如在某个时刻，client1 获取到了 5 个中的 2 个，client2 获取到了 5 个中的 2 个，它们都想去获取最后一个，但是只有一个能够成功获取，不会存在你说的死锁情况，因为不会出现“client1 持有 client2 需要的资源，client2 持有 client1 需要的资源”这种情况，不会构成一个环。

@popesaga #1
@bee7 #4

count++本身不是原子操作，但是代码里已经使用了内置锁保证了 count++的原子性。根本问题不是 count++，而是没有用锁保护好 count 这个共享可变变量，也就是两个线程可以“同时”执行 count < 100 判断。如果当前 count 是 99，奇线程执行判断成功，获取锁，但是在更新 count 值之前，这个时候奇线程中止了，轮到偶线程执行，虽然判断成功，但是没办法获取锁，不过等到奇线程释放锁之后，偶线程就可以获取到锁了，最后偶线程会打印出 100 。

@pangleon #19 “间隙锁又会引起别的 BUG”，可以详细说明一下是什么 bug 吗？谢谢。

其实我不太明白为什么这么多人都是在说 gap locking，文档里明明说的是 next-key locking 。

https://dev.mysql.com/doc/refman/8.0/en/innodb-next-key-locking.html 中说了“To prevent phantoms, InnoDB uses an algorithm called next-key locking that combines index-row locking with gap locking.”，很明显，单纯的 gap locking 是不能阻止幻读的，index-row locking 加上 gap locking 才能够解决。

@huntcool001 #12 +1，并没有完全解决。

https://dev.mysql.com/doc/refman/8.0/en/innodb-consistent-read.html 中也描述了这个问题。在“The snapshot of the database state applies to SELECT statements within a transaction, not necessarily to DML statements.”这段里面。

我们是使用 canal 统一管理缓存的清除，在调用方法前判断是否存在缓存，没有就获取 MySQL 的数据，然后缓存起来。在方法里面处理缓存相关的逻辑，个人觉得不太好，就像 AOP 一样，不要污染业务逻辑。

@zhangysh1995 你可以自己去执行一下，看看是不是等价的，如果是的话，麻烦分享一下语句，让我重现一下。