在一个群里被恶心坏了

我在 B 站看到一个微博架构师发的一些视频.觉得他讲的东西很实战,加了他的群,而且是哈尔滨的,我本人是佳木斯的所以对他非常有好感
今天上午群里在讨论事务隔离级别的问题.
本身就这一个技术问题大家有着不同的理解很正常,无论说的是对是错我觉得都没啥问题.
主要是针对 MySQL 的 RR 隔离级别下的幻读问题

这时候他表示没有锁就是幻读,还表示 Java 的锁就没学明白,我表达快照读就算不加锁同样没有幻读问题,除非你在事务里面修改了其他事务新增的数据,那就没办法了

然后就开始攻击我了,说官方文档写的清楚.

然后我去 MySQL 官方看,同时自己做了验证,我的理解是普通 Select 无论加不加锁,无论怎么查询都不会有幻读问题,如果 for update 或者 delete update 这种操作就会用临建锁或者间隙锁来保证一致.
所以他的结论"不加锁都是幻读" 就是不对的

还上升到 java 的锁,CopyOnWirteArrayList 不就是快照实现吗? 一个快照迭代器创建之后就是不会被其他线程影响啊,难道迭代器不加锁要被 add 影响吗? 无锁保证数据一致的方法多了,JcTool 里面好多队列都是

当我想把官方这个截图贴到群里的时候,我就已经被踢了. 我巨无语,一个资深技术专家可以这么讨论问题的.

然后我去 B 站质问他,果不其然 B 站也把我拉黑了

这就是架构师的格局吗开了眼了

我觉得无论我说的是不是对的,技术问题起码应该就事论事,直接开始人身攻击,属实牛

lambdaX999

227 天前

看了大部分评论都没有讨论 OP 提出的问题，我很想知道这个问题的真正结论是啥，到底是那个架构师错了，还是 OP 错了，为什么大家都在讨论架构师怎么样，OP 怎么样，对于 OP 核心的问题讨论甚少，希望能看到让我学习下。

另外这种通过视频引流拉的群，本身大多数 UP 都是希望通过这种方法卖课或者干点别的，俗称噶韭菜，当你在群里让他颜面扫地或者怼他的时候，他踢人确实正常。我之前在阿里的一个群里讨论别的产品都被踢了，格局低的基本都这样，我感觉也没必要生气，还是应该回到问题的本质，就事儿论事

chunzhang5748

227 天前

让我想起王迅跟一个教授在一个节目中讨论‘上善若水’的场景......

zzhaolei

227 天前

@liuzimin 卖课的，靠知识挣别人钱的，知识都了解的不对，就别怪别人说话直了

xuanbg

227 天前

自己知道就行了，没必要非要指出别人的错误。这也是尊重他人命运吧。。。

zzhaolei

227 天前

这不是诈骗吗，这能纵容？？？？

htxy1985

227 天前

所以，这个问题的答案是什么，还有人探讨下吗，就像 35 楼那样。

liuzimin

227 天前

@zzhaolei 如果是这个角度想，那我觉得楼主的口气反而轻了，直接就应该骂他丫的，什么傻逼架构师狗屁不懂你他妈卖个什么课。。。
不过如果从讨论技术的角度，楼主的口气又重了。

zzhaolei

227 天前

关于 MySQL 实际上的幻读问题： https://xiaolincoding.com/mysql/transaction/phantom.html
1.普通读是快照读，select for update 是当前读，当前读会加锁，基本上解决了幻读的问题
2.没有完全解决有两种情况会出现幻读，具体可以看这篇文章
2.1 第一个幻读场景我觉得不能这么用，用法就很奇怪

jackwaycn

227 天前

讨论问题意见不合很正常，可以就事论事摆证据，一言不合就踢人格局一下就低了

xiaoxixi08

227 天前

是要开发数据库？讨论这个有啥意义

0xLittleFi

227 天前

在 MySQL 中，幻读是一种特定情况下的并发控制问题，它发生在使用事务时，特别是在可重复读（ Repeatable Read ）隔离级别下。幻读是指在同一个事务内，当执行同样的查询时，第二次查询返回了第一次查询未出现的新行，这些新行是在第一次查询之后被其他事务插入的。

幻读通常与以下场景相关：

范围查询：

当一个事务在执行一个范围查询（如 SELECT * FROM table WHERE some_column BETWEEN value1 AND value2 ）时，如果在事务开始后，其他事务在这个范围内插入了新的行，那么在事务的后续查询中，这些新行将被看到，尽管它们在事务开始时并不存在。
索引间隙：

在 InnoDB 存储引擎中，使用行级锁和间隙锁（ Next-Key Locks ）来防止幻读。但是，如果查询不包含任何索引范围条件，或者索引选择性不高，导致锁定的是整张表或大范围数据，那么幻读仍然可能发生。
隔离级别：

在默认的可重复读隔离级别下，InnoDB 通过多版本并发控制（ MVCC ）防止脏读和不可重复读，但仍然可能遇到幻读。
要完全避免幻读，可以将隔离级别提升到序列化（ Serializable ）。这将对所有查询施加读锁，从而确保事务之间的一致性，但代价是降低了并发性能。
解决幻读的方法包括：

使用 SELECT ... FOR UPDATE：

在查询时添加 FOR UPDATE 子句，这会锁定查询到的行，直到事务结束。但这只适用于锁定已经存在的行，对于新插入的行，仍可能出现幻读。
提升隔离级别到 SERIALIZABLE：

这是最高的隔离级别，会阻止幻读，因为它会对整个查询进行锁定，相当于对事务执行时的数据库快照进行读取。但这种方法可能会导致大量的锁竞争和阻塞，降低系统性能。
使用特定的事务设计：

通过调整事务的逻辑，例如使用更大的事务粒度，或者避免在事务中进行范围查询，可以减少幻读的可能性。
请注意，幻读仅在特定隔离级别下发生，并且主要与并发事务插入新行有关。在读已提交（ Read Committed ）隔离级别下，由于每次查询都会看到最新的提交，因此幻读的概念并不适用。