不论大小，没有什么大的诱惑一律向钱看

已经凉了

go vet

是不是压根找不到符合需求的人？

都玩 go 了，下一个必须是 rust，py 是往上面学，你得往下面底层学

是你自己没有太早开始准备，现在终于忍不下去了。应该早作打算的，其他都不是借口，你真想把自己身体精神熬垮了？有什么比自己的健康更重要？专科不是借口，况且你已经有 5 年经验了，从今天，从现在开始，准备吧。

有啥用

你吃了蛋住院了，谁负责？

IP 限制

牛皮卷

https://mp.weixin.qq.com/s/SpVTl64W1Exy8fuN15-kmA
@bushenx

不用花精力组装，搬家也和笔记本一样方便，i9-10900+16G+512SSD 价格也才六七千
https://detail.tmall.com/item.htm?spm=a220m.1000858.1000725.13.482d2b55vNhPJk&id=615877324813&skuId=4653810529274&user_id=2207840445127&cat_id=2&is_b=1&rn=95f1ab89a09407f7b7fa5411443d6535

如果对便携的需求没那么强烈，推荐买 mini 整机，不缺性能，给个型号你了解 dell 7080 mff

@louettagfh 嗯，我昨天想明白了。不管有没有 change buffer，对于不在内存中的聚簇索引页，innodb 都会去读磁盘，然后内存修改聚簇索引页中的元数据，其实这个时候就已经拿到了 affected rows 。

然后才是轮到索引页的更新，change buffer 是针对索引页更新的优化，我之前没理清楚整个过程。

@louettagfh 官文中对于 change buffer 的描述是，它可以缓存所有对于 buffer pool 中不存在的二级索引的 DML 操作，可以不用去读磁盘获取实际数据（是有原话的）。我的疑问就是 update/delete 操作如果不读磁盘怎么可能拿得到 affected rows，换言之，我认为不论是 change buffer 还是 buffer pool，二者之一是一定去读了磁盘的，但不清楚具体逻辑，就很懵逼，全网搜遍也查不到相关资料，我要是会 Cpp 就直接去看源码了。

你的意思是当 buffer pool 中不存在待修改的二级索引时，innodb 还是会去读磁盘通过 B+树找到页，再找到记录并进行删除（标记），然后再去删除（标记）二级索引。 有相关资料描述这个过程吗？

@IamUNICODE 这只是解释什么是 affected rows

研发超过 100 个没有？

优化点：str 到 byte 之间转换用 unsafe.Pointer

开心的一天到本帖结束