首发 12mini，只剩下 89 了

把员工 A 的 id 作为交易明细的一个维度冗余进去呗？
然后就可以 select * from order where manager=员工 A

你看见她开着火进去洗澡你就把火关了东西倒了
倒多几次就会避着你了
然后你可以假装外出，中途再回马枪继续倒
倒多了应该就乖了

@cxxlxx 应该是直接算的硬盘连续读写速度吧
但是为啥 hive 会丢数？

@fengsien1999
#9 补充一个，为什么不招 Go?

新版本的 Mysql 的 null 用就是了
如果业务上面一个字段是可空且，那就应该设置为 nullable 的列
举个例子，有一列是采集用户的某个数据，假设是今天使用的电量吧
那未采集的状态就是 null，采集了一度电都没有用过就是 0，这里就需要显式区分没有采集的状态
当然你可以引入其它额外的标记位，或者引入 -1 类似的默认值
但是这样又会在求和求平均等场景引入额外的判断条件（ where cost != -1)
最自然的做法我觉得还是让列为 nullable 就可以了

reference: https://dev.mysql.com/doc/refman/5.7/en/innodb-row-format.html

@fenglangjuxu 他用 chan 排队了，一个协程专门处理 data，其它协程访问不到

原因应该是这样的，没有很深入看 map 的源码(src/runtime/map.go)，所以带有猜测成分
首先我们往 map 插入一个 key 为 id1 的
然后完成请求后，刚刚 key 所占用的 []byte 被重复利用，key 变成了 id2
猜测 map 的实现里面没有拷贝一次 string，所以 map 里面的 key 变成了 id2，但是 hash 还是之前 id1 的 hash
然后分两种情况:
- 新插入 id1，!t.key.equal(key, k), 所以给它分配了一个新的桶
- 新插入 id2，原有的 id2 跟新的 id2 hash 不相等，不会覆盖，还是给它新分配一个新的桶

可以通过一个小 demo，复现这个 case，获得一个 200 个 key，每个 key 都是 id1 的 map
func main(){
m := make(map[string]int)
for i := 0; i < 200; i++{
b := []byte("id2")
str := *(*string)(unsafe.Pointer(&b))
m[str]++
b[2] = '1'
}
fmt.Println(m)
fmt.Println(len(m))
}

app := fiber.New(fiber.Config{Prefork: false, Immutable: true})
这样写就正常了
初略看了下代码，不使用 immutable 时，框架是直接用 unsafe 把 []byte 转成 string 然后抛出
感觉跟内存块复用 /golang memory model 有关
具体还得仔细看看源码

@Lpl 是我单方面夸他...
1. 从代码来看，id 是 url path 里面取的，不固定
2. 谁主张谁举证，大佬 benchmark 来一个？我理解只是从锁排队变成了协程排队了而已

@lesismal
几乎同时回复了同一楼，不过大佬你讲得好多了😂

@Lpl
感觉你的 3 条怪怪的，但是说不出很具体很有说服力的理由。
尝试列举一下原因：
1. map 是用不到 atomic 的吧，没有 Google 到 atomic 跟 map 一起用的方法，如果 atomic.AddInt32(&m["a"],1) 会报错 can not take the address of m["id"],。
就算假设我们可以拿到 addr，那我们还需要额外处理 key 不存在的时候，map 桶分配等逻辑，这时候还需要两次 hash （查询是否存在时计算一次 hashkey，插入 /递增的时候再计算一次）。hash 应该比锁重多了吧。

2. 管道里面还是包含了一个锁，只是是拥有锁的时长变了，从“hash 需要的时间”变成了“写 channel 的时间”，但是 map 还是需要排队写入，引入个队列相当于脱裤子放屁，还引入了协程调度的开销。在这个 case 里面，map 应该是瓶颈，引入队列并没有解决这个问题。

3. 这种锁设计，根据官方文档“The Map type is optimized for two common use cases: (1) when the entry for a given key is only ever written once but read many times, as in caches that only grow, or (2) when multiple goroutines read, write, and overwrite entries for disjoint sets of keys. In these two cases, use of a Map may significantly reduce lock contention compared to a Go map paired with a separate Mutex or RWMutex.” 很明显不属于前者，然后需要 ++；后者也不属于，因为 id 在生产上更可能是均匀的，不同协程写的值域是有交集的，仍然会产生锁竞争，性能不一定比 map with RWMutex 好

@Lpl 我理解他这里的意思是，先保存下来当前的状态，然后重置 counter
这里的问题我理解只是重置全局 counter 的时候没有加锁，所以会丢失部分统计数据，但是不应该会如楼主所说“这里 abcde 就是相同的”

我 review 楼主的代码没有 review 出啥问题, 复现的成本对我来说有点高。
如果按照“这里 abcde 就是相同的” 这里来推断，因为 map 里面的 key 值都是唯一的，所以猜想可能楼主实际上使用的并不是 map[string]int, 而是自定义的结构体 /指针 /浮点数
然后多个不同的 id，虽然内容是一致的，但是 hashkey 不一致

拉到最后竟然没有公众号 /博客 /培训班 /招聘

抽象来说，就是你有 n 个数值，将其分成 m 组，设分组后每组和的最大值为 x，求 x 的最小值？

好像都没有提设计模式的
可以直接问设计模式，科班出身多多少少都知道点
培训班的就应该搞不过来了吧

把设备和代码都部署在远端呗，然后开放用有限权限的用户帐号登上去操作，那个帐号限定只能执行限定的命令

你们不打算加个美颜功能吗