在 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 ）隔离级别下，由于每次查询都会看到最新的提交，因此幻读的概念并不适用。

加 v 提示频繁，已经申请试用

金融游戏，最后比的还是谁跑的快。
让其他人的钱转移到你的口袋里，如果认知够，赚钱很快。如果刚入行，要交够学费才能提升认知。
俗话说的好：被套住了，就研究明白了
如果你有负债，家里没闲置的流动资金，尽量不要碰。
麻绳专挑细处断，有能抵抗风险的能力，并且脑袋清晰，该跑则跑，不和山寨谈恋爱。
不要总是想着能赚几倍，赚够你想要的。
普通人不要全职，除非你的资金很大，家里有矿。

以上是我被套几年的感悟

@halowang 其实有的，你这个大概率没跑起来，看下端口映射和服务进程有没有 pal 服务

@locoz 老哥，我配置修改后重启没生效，有遇到过吗

貌似配置没生效

@0xLittleFi 不对，已经跑起来了，感谢。 但是容器里的 root 密码是多少

8211 端口都没映射，怎么进的。。。

前端内部一套定义，从后端取值的时候防腐一层，后端很多时候取其他领域的数据也是这么做的。自身稳定，不稳定的交给防腐层做。

首先 mentor 得代码好，
企业级的代码，逻辑清晰是第一点，毕竟是要长期维护
如果 op 觉得他不行，可以申请换 mentor ，mentor 不会觉得你菜，重要的是会学，不理解就刨根问底

支持一下，冲！

确实是 op 所说的样子，一般来讲，绩效在里面算很重要的一环，导致所有做的事情都应该和绩效挂钩。如果到年底 review 的时候，发现和之前的绩效目标不一致，至少在老板看来，是不成功的。
选对领导，选对业务，加上努力；基本上熬过一年，建立起了信任，和组内，其他组打好关系，情商拔高，后面就顺风顺水了。

搞个多签，把其中一个签名给老板

@wangjiang 感觉不错 是天目里的店吗

杭州真的是美食荒漠了吗

@lingyan223 这个还行，就是有点辣，包厢不知道有没有