很少用，要用也是带其它条件字段将数据缩减到足够小的范围。正则走不了索引。而通常做查询时，先考虑走什么索引。

golang 之前确实有篇单机 100 万连接实践。本质上是讲 golang 在 100 万连接下怎么优化的。比较采用常规的一个链连接 2 个 go 程方案与通过 syscall
直接使用 epoll 方案之间的内存占用和延迟差别等。和 100 万并发不是同个概念。文章里实现单机 100 万连接的一些设置以及测试方式还是可以借鉴的。其它语言也能做到

存储和索引

分片。把两张表拉下来，根据公司 id 分片，存到磁盘上。然后一个一个分片加载到内存中计算。磁盘持久化的 b+树上千万级，性能下降很厉害。

看区域。大多区域已经被我爱我家，链家等中介公司垄断。极少数区域房东还坚持自己租。千万警惕二房东。我爱我家之类正规的，相当于花钱省麻烦。大多情况下不用和房东打交道。故障之类平台上报修，小东西会直接免费用。和房东打交道费力些。二房东往往收钱不办事，你还得和房东打简单。也有那种通过中介租的当二房东，听过没接触过。

共同探讨，有理有据完全可以接受

@hengyunabc 关于你说的仓库被攻击引入 hash 的问题。java 也存在，任何从仓库下载的都存在篡改问题。而且 go 也能做到从企业内部的仓库下载。

估计是一下子没找到问的方向，问这个看看你熟悉什么，然后再深入问

@byte10 runtime.LockOSThread()

入口代码在 src/runtime/proc.go 。有个 func main()

golang 的 runtime 源码在 src 可以直接找到。真正的 main 函数其实是在 runtime 里。然后你可以看到启动的步骤，包括不限于启动 g0 协程和启动 gc 工作。
每个 go 进程是自己独立的，和虚拟机区分开来。没有独立的 runtime 进程。
简单的讲，你可以理解成 c 语言加入了协程和 gc 的框架。由于有 gc，所以不能直接使用系统分配内存的函数，都是通过这个框架提供的函数来分配。

以前了解过。1.8 出来后想抽空尝试，刚好碰到项目里需要个小东西，挺合适最终效果也不错。现在我部门已经全是 golang 了

刚好手头就遇到一个场景。大致是中间层汇聚各种内容一起返回。但是只知道 key,以及值是一个 json 。某项 key 内容不存在时，你让中间层实例化也很为难啊，都不知道内容。

直接提 bug 。
接下来会安排到某个迭代由某个人解决。
改的人会分析影响范围。
改完也有回归测试。

我自己写的 b+树选择了不固定阶，key 有长度限制，value 不限。过大的 value 通过扩展页分割存储到多个页中。

页大小可以选择，决定了就固定了。所以要么 key 有长度限制，要么引入其它结构处理超大 key 和 value 。记得 mysql 是有 key 长限制的。最新的版本不清楚

@tlerbao 另外要说明的是，团队使用 rebase 方案，需要培训和约束的。否则请用 merge 方案。

@tlerbao 另外多个分支并行开发时。rebase 方案操作步骤会更多，我会使用本地临时分支

@tlerbao
确实会存在。rebase 方案这个地方确实不完美。只要分支开发提交到上游就会有。确认没问题后，删除这个分支也不影响。但是一般会保留用于追溯。由于基变导致 commit log 编号不同，需要靠 commit 说明来对比。虽然有瑕疵对比 merge 方案，我更喜欢 rebase 。