别光看性能数字，你还得看设计温度、设计功耗、对散热要求的提升，综合起来的提升，没那么高。CPU 的性能，从来都不是它能多快，而是在条件限制下允许它跑多块。

不让贷款买股票证券等高风险投资，这个应该是银监会的要求，不是银行主动想管得。你要糊弄的，不是银行，是银监会。

@tool2dx #7 零本万利的东西，它就不可能成为历史，网站流行度一高它就会让你知道它的存在。

https 最大的负作用就是运维麻烦，即使是 Let's Encrypt 提供了全自动化的脚本，它还是不如不搞简单。另外互联网档案馆这种公益性网站，对 https 多出来的加密处理，是性能敏感的。

Microsoft Authenticator （手机应用）对于微软账号来说是免密登陆器，不是 2FA 。对方只要输入邮箱地址，选择用 Authenticator 登录，你的 Authenticator 就会弹登录。你要没注意点了同意，对方就登录上你的账号了。

对方要是买了 Hotmail 邮箱地址，然后脚本逐个去尝试使用 Authenticator 登录的话，真有几率骗几个登录。实际影响应该不大，因为 Authenticator 和邮件都会有异地登录提示，后续改密码等敏感操作，还会再要求登录。但防不胜防，还是高危漏洞，微软要处理的。

@tool2dx 不传密码也要 https ，不然容易被人在中间加屎——比如 ISP 插个小广告。绝大部分内容网站都是需要 https 的。不需要 https ，或者 https 起负作用的，是临时网站、公益性网站，还有开发人员用得内网、IP 网站，等等。

http 升级 https 的目的只是防中间人攻击，并不是所有网站都需要防中间人攻击，比如你这个例子就属于没人敢攻击的情况。所以为什么要必须升级。

钉钉当然能做，任何 Windows 软件都能做，但是没必要，他的销售方向不在这里。整个办公环境，都要放到虚拟机里，不管有没有监控，个人环境和工作环境隔离，这是办公方式的需要，跟是否监控关系不大。

第一，自己要是管数据，那就不能像中国这样泄漏了跟没事一样，泄漏了可能要被罚破产，所以没特殊需要就外包。
第二，数据管理方要是不按协议使用数据，那也不能像中国这样被怀疑了跟没事一样，被合理怀疑又不辩解的时候，有很大的风险会丢失市场，进而破产，这方面是市场能自调节，都不需要监管的参与。
第三，一旦做大，那就不管你是中国还是欧美了，肯定是要自建的，这其实就是适应不同市场、不同阶段的选择，没啥定理。

@pkoukk #47 不要把按攻略跑图当探索。会抄攻略，看把你能的。

@pkoukk 你这玩法，不如开作弊器直接改数据，或者只看别人玩。另外建议你去玩下刺客信条 2 ，再来说它简单——刺客信条系列的跑酷难度是逐代降低的，到了起源其实压根就没跑酷了。

@axelv2 #30 一般类魂游戏是这样的，但老头环有纵深地图探索（比如说史东薇尔城 boss 旁边那个地下小 boss 及其前面非常容易摔死的路线），这期间别说经常没篝火，就是有篝火也没心情去用。其实探索期间累积的魂也没多少，但都是心血，掉了非常影响心情。

@BeforeTooLate #34 特么是语气词，脑残的对象是老头环的中文翻译，你非要往你自己身上带，那我也没办法。当然这条回复不是给你看的。

@kenvix #37 128bit 也就 16 字节，可以直接存储为二进制 16 字节，或者转储为 Hex 存储为字符串 32 长度/字节（绝大多数编码，英文数字都是单字节编码）。这大小在数据库场景中，从来都是忽略不计的。UUID 做主键的缺点从来不是占用存储，而是其不连续。另外，Int64 可不一定是 4 字节存储，因为数字在数据库中往往不是二进制，而是十进制存储的，比如 Oracle 。

@yukiiceqqq #11 死回篝火的时候鲁恩（ rune 符文）掉地上，去拾回来的时候半路死了就完全消失了，再配上老头环特有的多维空间超长探索路线：现在好好想想到底谁没下游戏。
@BeforeTooLate #13 瞎几把跟着起哄。

类魂，别看这几年那么疯，实际上大多数人买了玩不了，还是让它赶紧静静的死去吧。老头环这种魂系的机制配上类似古墓丽影、刺客信条那样的探索地图，更特么是劝退大坑——几个小时的探索结果，一个突然冒出来的 boss 再加一个不小心的跳崖，就全都没了。就更别说那英转日再转中的脑残翻译了。

@MoYi123 #29 消息队列读写分离了，可以单独只对读那一瞬间加锁。10 楼说得明明白白。

@catamaran #29
@kenvix #31
上了高层面，数据设计上就要区分事务性数据和分析性数据了。用于常用业务的事务性数据，数据量往往十万都到不了，这时候离散的 UUID 就是首选。偶尔数据量上去的事务性数据，比如 twitter 这种体量的用户，也是换用雪花 ID 来同时保持离散跟顺序，不搞顺序而不离散的数字。分析性数据，用 UUID 就不合适。

@Vegetable #25
update table set status = 'work' where id = 1 and stats = 'ready'
id = 1 怎么来的：是 select id from table where stauts= 未处理 limit 1 得到的
那要是 select 语句跟 update 语句之间，其他线程已经提前做了 update 呢：这个 update 会返回 0 ，本线程处理失败
接着呢：如果你当失败处理，那么这个线程没了；如果你重新 select ，那么大部分时间要消耗在 select -> update return 0 -> select 的死循环中了。

我对 @MoYi123 第一个回复确实是错了，不是表锁，而是乐观锁。但乐观锁不解决问题，详见我上面对 yjhatfdu2 的回复。

楼主这个场景要加锁，你只能对 「 where stauts= 未处理 」，或者「全表」加锁，加了之后多线程从并发变排队，形同单线程。

@yjhatfdu2 #18
https://stackoverflow.com/questions/53288584/select-for-update-skip-locked-in-repetable-read-transactions
看下 skip locked 的效果，可以重复加锁，但是事务提交的时候要判定数据有没有被更改过，如果已经更改，那么本事务要失败。这就是个乐观锁，先提交的成功，后提交的失败，使用场景是并发修改的机率不高的场景。如果你在多线程并发场景中用乐观锁，那没跑几步就会只剩一个线程活着，其他线程全部出错终止（加了出错之后重启机制，效果会更差，绝大部分性能将被浪费在失败重启上）。

事务不是一句「开事务」就完事大吉的。什么时候开事务，开什么样的事务，都是有考究的。最常见的错误，就是认为开了事务就不怕并发数据冲突了。事务的隔离性是分级别的，序列化级别才能保证完全不出现并发数据冲突——但同时也没并发了。常用的隔离级别是可重复读，只在并发数据是确定的单行/多行数据的时候才能保证无并发冲突，当并发数据是表，或者表中不确定的数据时，还是要加锁处理并发冲突的。

而怎么加锁，也是有考究的。楼主的场景是没法加锁的，因为它的并发数据是「 stauts = 未处理」的表，不是「主键 = xxx 」的行。加常规悲观锁就让线程排队，等同于失去并发。加乐观锁，就是开玩笑。

@qviqvi #21 不要只找简单答案，容易错。Karte 那三个方案才是正确的。