@DearMark gap 编什么理由都没区别吧

@zhou405x 专业背调是什么样的？

黑神话悟空

@hanssx 现在二本进得去 体制/国企/研究所 吗

自学学个初级水平没什么用

从来没遇过这样的 奇葩

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

@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 能读到