@COOOOOOde 这个用 ai 补全很痛苦，全是 1.0 的写法，很多都要自己去扒文档看

松鼠快看

MySQL 的 InnoDB 存储引擎用行级锁来实现多版本并发控制（ MVCC ），同时也支持 "SELECT ... FOR UPDATE" 这种显式锁定。在解决超售问题的场景中，死锁的出现可能是由于并发事务试图在同一时间内锁定同一行数据导致的。

对于你的第一种 SQL 语句：

```
UPDATE inventory SET stock = stock - Y WHERE product_id = X AND stock >= Y;
```
这个语句在更新前会先检查 stock >= Y 条件，如果不满足这个条件，该行不会被锁定也不会被更新。当你有多个并发事务试图更新同一个 product_id ，并且 stock 库存不足时，这些事务可能会互相等待其他事务释放锁，这就可能导致死锁。

对于你的第二种 SQL 语句：

```
SELECT stock FROM inventory WHERE product_id = X FOR UPDATE;
UPDATE inventory SET stock = stock - Y WHERE product_id = X;
```
在这个情况下，你先显式地获取了一个行级锁，这会阻止其他事务在此期间修改这一行。然后，你再执行更新操作。由于你已经持有了行级锁，所以其他试图更新这一行的事务会被阻塞，直到你的事务完成，这样就避免了死锁。

总的来说，第一种 SQL 语句在高并发的情况下可能会导致死锁，因为它试图在同一时间内更新同一行。而第二种 SQL 语句通过显式获取行级锁来避免这个问题。这就是为什么第二种 SQL 语句在你的测试中没有出现死锁。

搞点副业，做知识付费

散热效果好、便宜、静音，三选二

弄了一个 12400 的 deskmini b660 ，32G 内存，挂机跑 QQ 机器人

用习惯了，人脑会自动切换，一摸键盘就知道应该用什么键位按快捷键

同 5800H ，用两个瓶盖把后面的脚垫垫起来，散热效果好很多

看这个界面像是 kibana ，是不是 elk 日志收集的时间间隔 1ms ，实际产生日志的时间间隔不止 1ms ？

AMD Ryzen 7 5800x
ASUS TUF GAMING B550M-PLUS
Galaxy RTX 3070 GAMER OC
G.SKILL DDR4 3600 16Gx2
Samsung 970evo plus 512G
主要用来看 b 站、逛贴吧和斗鱼云游戏

blunt classic，用了 4 年了，满足又大又坚固（可以抗台风），就是比较重

jsoup

遇到同样问题，给个解决方案：我用的 zsh，把~/.zshrc 中 export LANG=en_US.UTF-8 前面的#去掉，再 source ~/.zshrc 即可

为所欲为，精益求精

@weiran 是刷哪里的固件可以支持 970 evo plus ？可以发个相关链接吗

三星 970EVO PLUS 目前没有办法驱动，装黑苹果无限重启

有个考核指标叫做平均下班时间

@BlueSky002 1、全自动不支持-s 参数； 2、使用的-s 方式也不对，应该是 1080x1920 ； 3、自动模式在 1080x1920 分辨率下需要调整 ratio，个人测试 1.374 是个不错的值。

@hardman 稍微等会就好