从来没遇过这样的 奇葩

但你的问题就算不考虑存钱的问题，那也不是当程序员的问题啊，起点比较低在外包工作，这不是很多人都有的普通的经历吗。现在找不到工作的码农多了去了，也并非都不是能力不行。

@dearliuliu 那入职了之后按照你的意思 还得拼命表现，富有干劲? 这不适合所有吧

为什么不存钱呢

看了下帖子貌似二三线城市 社保这方面缺失比一线城市差不少

法律上不允许，但实际操作大多都不遵守。没人举报就当没事发生

真实

@ymz 5 点下班也有的

英语提升最好还是输出 不只是看

@yjhatfdu2 第一次知道

@wenxueywx 事务中 加锁之后 进行了快照读，在目前仅有的业务下，在什么情况会出现读不到最新数据？

@wenxueywx
根据本人目前掌握理解的水平， 如果主表不加锁， a 事务和 b 事务 都分别各自按照下面 sql 执行执行


====sessionA
begin;
UPDATE a_detail set approval_status = 2 WHERE id = 1 and approval_status = 1;
select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ；
commit;
=====sessionB
begin;
UPDATE a_detail set approval_status = 2 WHERE id = 2 and approval_status = 1;
select count(0) from a_detail WHERE auid = 'a1' and approval_status!=2 lock in share mode ；
commit;
各自执行 update where id=都会加上各自 id 的行锁，
但各自执行到 select count()都要去根据 auid 这个非唯一索引进行等值查询，都会触发各自的间隙锁，但是又与对方事务的行锁冲突，造成死锁

@wenxueywx 你的意思是在每个事务里 ，先 update 各自 id 的状态，后执行 select count(*) from a_detail where approval_status!=3 and auid='a1' lock in share mode;
吗 ，实测下来 select count(*) lock in share mode;会阻塞，死锁。 是我理解执行有问题吗

@wenxueywx 原先就是设想 在 rr 级别为了 让 count 操作串行执而利用行锁，并且让 count 操作在获取行锁立马执行，确保能读到已经提交的数据。所以说本来的意思想 A 事务已经提交的数据，B 事务是通过 readview 能读到

@wenxueywx A 、B 两个事务并行，A 事务已经提交的数据，B 事务是通过 readview 是读不到的。
这句话也是错的 ，rr 级别根据 mvcc 生成 readview ，那按照你说的话，在 rr 级别只要 b 事务和 a 事务同时开启，b 事务就永远不可能读到 a 事务已提交的数据吗，但实际不是的

@wenxueywx
rr 等级的 readview 是事务开始时创建 .这句话是错的

@wengyanbin 而且只要能获取到行锁，说明上个事务已经提交了

@rqxiao 只要能获取到行锁，说明上个事务已经提交了

@wengyanbin rr 级别在 在事务开启后第一次发生快照读的时候生成 readview 而非 事务开启时生成 readview 。所以后获取到行锁的事务在 update 自己的记录后，count （ 0 ）就是等于 0 。
如果按照你的说法，在 rr 级别，那第二个事务也永远不会 count=0 了？
因为根据 mvcc ，他确实会读取到事务一提交完的数据，你可以自己测试下。count 的结果和事务开始的时间无关，和第一次进行快照读有关
而且幻读的定义不是事务中，同时进行两次 查询发现 count 数量不一致，这个场景一个事务里没有 count 多次啊？

如果理解有误请指出