ucando

听起来就很扯，完全是以他们利益最大化来考量。1.如果你被招过去了，他们节省了开支。2.如果没有招你，意味着他们找到了更好的，还能把你优化掉，同样节省了开支。
总之在他们眼里，你是可以被牺牲掉的，没给你一个有保障的选项就是个坑。

首先说说换电，它没有通用标准，只能蔚来自己用，怎么看都是一个笨重的固定资产，它既限制了企业对新平台新架构的开发意愿，又增加了运营亏损的风险。
再说说定位，在新能源爆发的年代，它把逼格拉太高，把很大一部分用户排除在外，在你还没有这个实力的时候做这样的事，在我看来就是笑话。参考小米，拼多多，抖音这些较新的巨头，哪个不是靠庞大的用户基数？由奢入俭难，现在再想回头已经有点晚了。

只能说现在中国的企业吃的都是人口红利，人多，学历尽情卡

又一次刷新了认知

有点不是太理解需求，如果是后付费，是不是可以理解成用户有多个需要扣费的业务，然后在某一个时间点需要自动扣费？以我的理解这部分并不需要并行处理，因为不是用户通过多个客户端同时操作进行的，直接照#13 楼的处理方式就行了。如果需要返回余额，还可以使用 returning fldBalance 来获取最新的余额，select 都省了

@hangszhang 文章里已经说明了 MVCC 下幻读的触发条件了，能让同一事务中的同一条查询 SQL 产生不同的结果。
A 事务：SELECT * FROM users WHERE AGE > 10 AND AGE <30; 返回 2 条结果。
B 事务：INSERT INTO users(gmt_create, age, name) values(now(), 20, 'Paidaxing999'); COMMIT;
A 事务：UPDATE users set name = "Paidaxing888" where age = 20;
A 事务：SELECT * FROM users WHERE AGE > 10 AND AGE <30; 返回 3 条结果。

@tedzhou1221 文章里也说了 mvcc 并不能解决所有情况的幻读，所以问题其实还在。一般情况下一个事务中是会对某些表做增删改的操作的，那就一定会有当前读的操作，如果仅仅解决快照读的幻读问题，还是不能保证不出问题。反正我做这种操作前一定会加锁，不指望靠这些默认的逻辑来保障数据安全

平时用 postgresql 比较多，刚刚粗浅地看了下题主说的幻读问题，然后想想“勇哥”的观点：不上锁都是幻读，虽然题主提出这是错的，举了快照读是无锁的例子，但快照读明明就是有可能发生幻读的呀，难道是我理解错了？其实“勇哥”是不是想表达“不上锁的事务都有可能发生幻读”呢？按我的理解幻读都出现在事务中，是要针对查询出来的结果做其它操作才会有影响，不在事务中的单条查询要么出来的是其它事务提交前的数据，要么出来的是其它事务提交后的数据，都不存在幻读的概念了吧？大牛们请指教

@Morii 简直是超级良心了
@HashV2 提的时候有事先看一下条文的规定, 也对人事的这些要求提出了质疑, 并没有同意人事的说法. 后面尝试找了一下, 确实找不到, 也打电话和社保局确认了是有社保记录就可以, 后面和人事又再一次沟通, 还是不肯让步.
@naminokoe @jgh004 @yulgang @shizhibuyu2023 确实也想过, 如果能爽快给个 n+1 也行, 自己走要么找到很理想的, 否则很亏呀, 特别是现在大环境不是很好