ezwd

@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 ？