要看是读多写少还是写多读少啊。
读多写少用第二种，写多读少用第一种。用列存储的话用第一种，如果是 B 树存储结构的用第二种，B+的可以考虑第一种。

如果第一种，aid 不能使用自增 id，需要自己生成和 tid 有关的 id，否则 B 表横向扩展会有问题。

@nockyQ #14 面试官想要的答案

lz 有没有试过 skip 几万条数据，有多慢？
正确答案是改用 seek limit 方式。

搜到一篇文章，希望帮到你： https://www.jb51.net/article/159126.htm

楼主的意思是，这个 order 并不是“稳定排序”。这的确有点奇怪，假设 recommend 是 timestamp 字段，我按照时间排序（当然会有重复），然后分页返回，按道理第一页的数据和第二页的数据应该不相同才对。

可能 pg 需要你指定第二个排序键才能保证“稳定”啊

我现在就断网 6 分钟试试，回头告诉你

跟能力有关系，能力强的，代码一次性写好，能力弱的，只能优化好几次

json.Unmarshal 成 map 啊，然后对 map 操作，完了再 json.Marshal 回去

@shawndev 对，HMAC 就是基于哈希函数的签名算法

应该说用到签名算法，哈希只是函数不是算法。
签名算法可以用 hash+id+secretkey+验证函数，也可以用 RSA 签名算法

还在讨论 touchbar 有无用的真买过 macbook 吗？现在都标配了，想不要都不行。

估计是 stop the world 了

@kaedea
@cmdOptionKana
Google Golang Escape Analysis

回答"写 Java 的倒是比较少转 go"
对于 Java 开发者而言，OOP 是圣经，OOP 标准只有一个，其他都是邪教。

第一台 T400，用两年坏屏幕，三年坏键盘，电池充不了电，铰链断裂，好处是当年你可以淘宝上能买到可以完整组装一台 T400 的配件。塑料的外壳用久了会断裂，更换不用花很多钱。

第二台 MBP13 2014mid，用到现在 2020 年了，没有任何故障，电池 78%。铝合金外壳，磕了会变形，更换很费钱，反正我没磕坏过。

PS：自从 T400 以后，换了键盘，就再也没有考虑过 thinkpad 了。
PSS：自从 MBP 换了蝶式后，就一直在观望了，好消息是 MBP16 换回剪刀脚了，准备新出的 MBP14 也要换新键盘了。

但联想是不会有希望的了

@RedisMasterNode 我想补充一下，关于”100%印象中好像并不是什么推荐的实践？“

的确，如果你站在研发人员的角度上看。当如果站在研发管理角度上看，情况会变得不一样。
如果你是个人开发者，或者几个人的开发小组，你信任你的成员职业素质都很高，那么你是可以相信研发人员都在必要的地方加上了单元测试。
但是如果你管理的是几十人的研发团队，你会确信他们的职业素质都足够高么？他们中就没有一个人会因为偷懒，没有在必要的地方加上单元测试？如果你不要求 100%覆盖，那么就有了讨价还价的余地，90%？ 95%？ 99%？哪个才合适？无法拍脑袋定一个数。

那些”防御性代码“问题，只是极少概率事件，而且研发上也能用技术解决。但管理上可选择的余地并不比技术上多。

@mitu9527 我领导是技术出身的。我们经历了差不多两年的软件质量问题，我们尝试过各种方法去改善，我们还实施过 100%接口覆盖测试，但收效甚微。可能是因为走投无路了，什么方法都试一下，所以才决定试试单元测试这条路。

@RedisMasterNode 我也向领导提过，当我的代码里出现“防御性代码”时，要覆盖它就变得非常困难，实际操作中，我可能为了避免写单元测试，把防御性代码撤销掉。
但 100%覆盖是“政治性”要求，没有商量的余地，而实际执行中，的确挺恶心。但也驱使着大家在写代码的时候，同时也思考着如何写出可测试的代码，间接地也提高了代码质量。实际上，我真的遇到了上面提到的“防御性代码”问题，但良心驱使我不能把这行代码删掉，解决的办法就是利用函数变量，在单元测试的时候把一些函数 mock 掉。

当然我们无法评价 100%覆盖所带来的价值，毕竟无法控制所有时空变量来比较，简单说，带来的价值无法量化，所以无法比较。

但从逻辑推理上说，还是有价值的，例如实施单元测试肯定对代码质量有所提升，我们重构的时候更加容易，合并主干的时候心里更有底气。

但我必须说，100%单元测试覆盖是一种倒逼行为，我们还需要正向的研发指导和程序架构设计，否者这个过程会很痛苦和很漫长。