@zuisong 你这个估计开不了发票出来，官网买又超了一点点好像

@zhongjun96 binlog 同步到 clickhouse 或者 es 直接查询，相当于用双倍的空间分别支撑 OLTP 和 OLTP 查询，如果能接受较长延迟 /执行耗时，或者说有超大批量查询要求的话应该转移到离线数仓去。

@Famio @OutOfMemoryError 对了还有一个原因是因为有些 sharding 算法并不是简单的取余，也是因为业务的特殊原因，需要实现一些奇奇怪怪的内容进去，所以不能只依靠 partition

@thinkingbullet Nice to hear. 不管好不好用，可以了解一下，感谢~

@kiddingU resolver 只解决连不同 db 的问题吧，好像不是解决分表的问题的

@Famio
@OutOfMemoryError
有历史原因的 Partition 有些场景不让使用（不管它是否好用，但是出于某些原因确实是不能使用）

@EAFA0 嗯嗯是个方案，我们现在也在用这样的写法

@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 譬如可以怎么改进？