@zhongjun96 一般有扫表的方案和异构存储 /离线数仓的方案；另外在决定分表之前也是需要考虑业务是否要频繁的批量查询，如果非常多批量操作的话，设计的时候要看能不能把分表依据和批量操作的依据结合起来，或者不用分表的方案实现

@Nooooobycat 也是个解决方案

@dobelee 在理

@dobelee 我们也是这么做的，确实稳健，所有的流程都能在 debug 的时候看清楚，其实就是相当于嵌入业务了，能感知到，坏处在于多加几行代码，库表越多，写得越多

一加 6 LineageOS 用户路过，后面 LineageOS 不支持了吗？用着体验挺好的，我喜欢极致的轻量，最好什么应用都不要有哈哈哈，一加是这么多年的最佳选择

@huigeer 除了待遇还会有其他的因素影响是否要继续下去

@gunitunit
1. 面试不通过的原因自然是不得而知，很大程度会是答得不让面试官满意吧，可以是深度不够，也可以是广度不够，这些不重要。
2. 通俗来说怎么向别人更好地介绍你接触的业务，同时让别人有可以入手提问的角度。譬如如果你做了一个收款打款（业务表述）的东西，那换个话术讲它可能是一套数据强一致的 CRUD （技术表述）；又譬如我做了一个短网址服务（业务），那它本质上是一个流量入口，是一个承载 xx QPS 的业务网关（这个描述可能不太合适，但总会有合适的模型能套在你的业务上），它该具有 xx QPS 服务应该有的什么特点（例如可用性、性能、限流熔断 bla bla ）。工作得越久，业务越复杂，越应该想办法让它能在数十秒内让别人听明白（哪怕有一些偏差，也远胜于摸不着头脑）。

@skywalkerfc 这个主要跟面试官挂钩，其实企业也只能提供有限的指引

@xuzhzzz
@skywalkerfc 富途

@JiangYon 总结一下我学 /复习 golang 的路径
1. 看了 go by example 和 learn go with tests 熟悉了基础的语法
2. 后续购入 & 认真读过的 Golang 读物（时间顺序）：
- Go 语言核心编程：读完，了解基本的坑
- Go 语言编程之旅：读完，教会我写项目
- Go 专家编程：读完，了解了常用数据结构的实现
- Go 语言设计与实现：读了一部分，比较多科班的内容考验读者基本功
- Go 语言底层原理剖析：读了一部分，代码有点多，抽象不够，考验耐心
- Go 程序员面试笔试宝典：读了一部分，Q&A 的形式，八股文大杂烩

我觉得你这样问的话，可能主要看有多少时间准备吧。如果你在未来半年内不考虑面试，那应该是有时间吃透其中几本书的；如果马上就要面试了，或许更推荐以抽象程度比较高的博客、文章为主。

@wbd31 大部分题目谷歌一下都会有详细答案的，如果找了还没明确的话欢迎再回复讨论

@liprais 譬如可以怎么改进？

重新看了一眼楼主需求：
本着节约服务器资源（省钱）的思想

觉得这个不应该换 golang...

@lazyfighter 3F 我已经回复过了会阻塞.....

复现成功插个眼蹲一手答案，另外几个测试 case：
1. insert into t VALUES (6,5,6); -- 阻塞
2. insert into t VALUES (6,4,6); -- 执行

不靠谱猜测：
1. 阻塞肯定是因为锁定区域有重叠；
2. 既然重叠那肯定是猜测 session A 锁定了 [10, 15] 这部分，session B 锁定了 [5, 10] 的这部分（边界是开区间闭区间暂且不进行确认，但是必然是有重叠区域的，例如这里的猜测 [10]）。

其他的提示信息：
1. Explain 结果显示 session A 的查询使用了 Backward index scan ，提示这里对 idx_c 的使用是反向的，因此 15 的 Next-Key 是 10 （可能）没错。

蹲一手答案。

@YadongZhang 说的太对了

很多时候只是因为开源了某个项目 /服务 /代码，其他人可以自由使用，不代表使用一定就得不收钱

以前压制组做过比较久的时间，说一下组里面一些比较实践向的做法（但不一定科学、有依据）。

我们在拿到 1080p 的蓝光原盘的时候，通常需要决定要转码成 1080p + 720p 发布，还是仅仅产出 720p ，那这个决定的因素在于蓝光原盘本身是否具有 1080p 级别的细节，因此反向考虑，如果它压缩成 720p 后，再拉伸至 1080p ，如果画面跟原来的 1080p 没什么区别，那说明它就只具有 720p 级别的细节。

4K 也可以做一样的处理，如果 4K resize 到 1080p ，再 resize 到 4k ，前后比较一下差别明显的话，说明有 4k 存在的意义，否则只需要保留 1080p 即可。

不科学的地方在于 “比较” 的过程是靠肉眼看的，那每个人的所见、感受肯定是有差异的，只能说对于从低分辨率拉伸上去的源，跟原生高分辨率 & 高码率拍摄的源，差距是非常明显能判断的；但是一些高分辨率 & 低码率的素材在 resize 过程中变化比较暧昧，就很见仁见智了。

@MeteorVIP 其实不刷流量，赚魔力值也行呀，反正挂着也是白浪费电费，性能不用追求太多咧

@GeruzoniAnsasu 我看你的描述很多时候只需要 wait group 吧。。wait group 的使用非常简单，只有需要 goroutine 间通信的时候才会需要 channel 呀，业务应用里面 goroutine 大部分场景都是用来并行做一些事情，例如并行发起 http 调用，我 golang 用了有小几年了没有感觉到什么不适而且觉得很好理解

当然你可能在描述一些多个 channel 之间共同协作，需要知道互相的结果，需要传递数据的情况，我不了解在其他语言怎么做的，但是我觉得常规开发里面写出这样的逻辑设计本来就已经对可读性不友好了，不能说只怪 golang 吧