@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 你可以自己去执行一下，看看是不是等价的，如果是的话，麻烦分享一下语句，让我重现一下。

@no1xsyzy #6
@leoleoasd #9

虽然说 a left join b on a.bid = b.id 和 b right join a on a.bid = b.id 得到的结果是一样的，但是因为它们的 a 和 b 的顺序还是会造成处理的性能差异的，具体可以看看“Database System Concepts 6th edition - Chapter 12 Query Processing - 12.5 Join Operation”，因为内容是在太多了，在评论里讲不清楚。

@zhangysh1995 #13

你说“WHERE 和 ON 在 JOIN 情况下没有什么区别”，你是说 inner join 吗？如果是的话，你说得没错，但是我想更加明确地说出，where 和 on 在 outer join 的表现是有区别的。

在“Database System Concepts 6th edition - Chapter 4 Intermediate SQL - 4.1 Join Expressions - 4.1.1 Join Conditions”中，说了“However, there are two good reasons for introducing the on condition. First, we shall see shortly that for a kind of join called an outer join, on conditions do behave in a manner different from where conditions. Second, an SQL query is often more readable by humans if the join condition is specified in the on clause and the rest of the conditions appear in the where clause.”。之后在“4.1.2 Outer Joins”中，它说“As we noted earlier, on and where behave differently for outer join. The reason for this is that outer join adds null-padded tuples only for those tuples that do not contribute to the result of the corresponding inner join. The on condition is part of the outer join specification, but a where clause is not.”。

我这里用例子演示一下 on 和 where 的区别吧。
create table t1(c1 int);
create table t2(c2 int);
insert into t1 values(1),(2),(3);
insert into t2 values(1);

select t1.*, t2.* from t1 left join t2 on t1.c1 = t2.c2; 的结果为
+------+------+
| c1 | c2 |
+------+------+
| 1 | 1 |
| 2 | NULL |
| 3 | NULL |
+------+------+

select t1.*, t2.* from t1 left join t2 on true where t1.c1 = t2.c2; 的结果为
+------+------+
| c1 | c2 |
+------+------+
| 1 | 1 |
+------+------+

@xgfan 我现在是使用 String 替代枚举作为替代应急措施，但是我更希望 Jackson 自身能够实现"保存 Map 中 key 的类型信息"，因为不能改用其他的序列化 /反序列化机制。

@hanssx #8 https://stackoverflow.com/a/47451071/5232255，这个回答或许对你有帮助。我暂时没有找到更好的方法。

@hanssx #5 谁先谁后“只能”通过最后的执行计划确定（“只能”加上双引号是因为有些还是可以直接看出来的）。如果 select 先执行，那么`select column1 from t order by column2`怎么能够成功执行呢？说 order by 先执行，`select column1 from t order by column1`，如果 t 有很多列，那么先执行 select，然后再执行 order by，肯定性能会更好。

@hanssx #4 第一条和第三条回复加起来就能够解释为什么两者不一样了，你的理解是对的。

@JasonLaw #1 第一条回复加上 https://stackoverflow.com/questions/14104055/ordering-by-specific-field-value-first/14104090 应该能够解答你的疑问。

@JasonLaw #1 不好意思，看错了

请教一：order by 1+1 不等价于 order by 2 的原因？
这是因为你的表只有一列，所以会报错，你可以使用`order by 1`试试。

请教二：order by (select 0)不等价于 order by 0 的原因？
同样的道理，`order by ordinal`中的 ordinal 要大于 0，小于等于表的列数

详细请看 https://stackoverflow.com/questions/11353688/what-is-this-order-by-1

注意：官方文档有这么一句话
Use of column positions is deprecated because the syntax has been removed from the SQL standard.

@izgnod #3 好的，期待你的回复。

@izgnod #1 我做了以下实验，事实并不是你所说的那样，并不是“插入前获取辅助索引的插入意向锁，插入后获取主键的记录锁”。而且问题中的两个 schedules 也能证明你所说的是不正确的。

create table t2(id int primary key, value int, index ix_t2_value(value));
insert into t2 values (5,10),(10,5);

-- session 1
start transaction;
select * from t2 where id = 3 for share;

-- session 2
start transaction;
insert into t2 values (2, 8); -- 等待获取 PRIMARY 索引上的插入意向锁(-∞ , 5)

select * from performance_schema.data_locks 的输出为：

+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+------------------------+-------------+-----------+
| ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+------------------------+-------------+-----------+
| INNODB | 140311361761480:1063:140311280045776 | 2072 | 50 | 14 | test | t2 | NULL | NULL | NULL | 140311280045776 | TABLE | IX | GRANTED | NULL |
| INNODB | 140311361761480:2:4:2:140311280042864 | 2072 | 50 | 14 | test | t2 | NULL | NULL | PRIMARY | 140311280042864 | RECORD | X,GAP,INSERT_INTENTION | WAITING | 5 |
| INNODB | 140311361760632:1063:140311280039632 | 421786338471288 | 48 | 22 | test | t2 | NULL | NULL | NULL | 140311280039632 | TABLE | IS | GRANTED | NULL |
| INNODB | 140311361760632:2:4:2:140311280036640 | 421786338471288 | 48 | 22 | test | t2 | NULL | NULL | PRIMARY | 140311280036640 | RECORD | S,GAP | GRANTED | 5 |
+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+------------+-----------------------+-----------+------------------------+-------------+-----------+



---



create table t2(id int primary key, value int, index ix_t2_value(value));
insert into t2 values (5,10),(10,5);

-- session 1
start transaction;
select * from t2 where value = 3 for share;

-- session 2
start transaction;
insert into t2 values (8, 2); -- 等待获取 ix_t2_value 索引上的插入意向锁(-∞, (5, 10))

select * from performance_schema.data_locks 的输出为：

+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-------------+-----------------------+-----------+------------------------+-------------+-----------+
| ENGINE | ENGINE_LOCK_ID | ENGINE_TRANSACTION_ID | THREAD_ID | EVENT_ID | OBJECT_SCHEMA | OBJECT_NAME | PARTITION_NAME | SUBPARTITION_NAME | INDEX_NAME | OBJECT_INSTANCE_BEGIN | LOCK_TYPE | LOCK_MODE | LOCK_STATUS | LOCK_DATA |
+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-------------+-----------------------+-----------+------------------------+-------------+-----------+
| INNODB | 140311361761480:1063:140311280045776 | 2073 | 50 | 18 | test | t2 | NULL | NULL | NULL | 140311280045776 | TABLE | IX | GRANTED | NULL |
| INNODB | 140311361761480:2:5:3:140311280042864 | 2073 | 50 | 18 | test | t2 | NULL | NULL | ix_t2_value | 140311280042864 | RECORD | X,GAP,INSERT_INTENTION | WAITING | 5, 10 |
| INNODB | 140311361760632:1063:140311280039632 | 421786338471288 | 48 | 26 | test | t2 | NULL | NULL | NULL | 140311280039632 | TABLE | IS | GRANTED | NULL |
| INNODB | 140311361760632:2:5:3:140311280036640 | 421786338471288 | 48 | 26 | test | t2 | NULL | NULL | ix_t2_value | 140311280036640 | RECORD | S,GAP | GRANTED | 5, 10 |
+--------+---------------------------------------+-----------------------+-----------+----------+---------------+-------------+----------------+-------------------+-------------+-----------------------+-----------+------------------------+-------------+-----------+

@azygote #5 谢谢🙏

最后的代码为：

PolymorphicTypeValidator ptv = BasicPolymorphicTypeValidator.builder()
.allowIfSubType(ImmutableMap.class)
.build();
ObjectMapper objectMapper = JsonMapper.builder()
.addModule(new GuavaModule())
.activateDefaultTyping(ptv, ObjectMapper.DefaultTyping.EVERYTHING)
.build();

Map<Integer, Integer> map1 = ImmutableMap.of(1, 1);

// content 为`["com.google.common.collect.SingletonImmutableBiMap",{"1":1}]`
String content = objectMapper.writeValueAsString(map1);
// 能够成功反序列化
Map<Integer, Integer> map2 = objectMapper.readValue(content, new TypeReference<Map<Integer, Integer>>() {
});