众所周知当你被技术面试的时候可能往往会被非常默契反复问一模一样的问题，如果你没答出来上网上搜索还能看到一堆详解我们称之为“面经”或者八股文。
Q: MySQL UUID和自增ID有什么区别？
首先我真的从来没有认真想过为什么要用UUID当主键这回事，如果你是单机DB,那么自增主键显然是一个非常自然且唯一的选择，如果你想用分布式DB,那么选择TIDB之类的NewSQL它依然会给你一个全局自增的主键，问题的关键是NewSQL的全局强一致性的确可以存在一个这样的全局状态。
然而当你搜索这个问题时你会发现网上存在很多解说主键聚簇索引的文章。
Q: 一条SQL太慢了你会怎么办？
“呃，加索引，没了。”
Q: 就这样吗？有没有可能你的SQL命中行数就是很少还是很慢？
a few moments late…..
Q: 你还有什么想问的？
“我还是想知道你说的SQL命中行数很少为什么可能很慢”
Q: 有没有可能，就是一次数据拿得太多了？
“啊？”
Q：有没有可能，就算拿得行数不多，命中也不多，如果表太大也会很慢？如果表超过两千万行我需要分库分表
“如果真的有那种需求我为什么不去用NewSQL。比如TIDB”
然而我会向你解释为什么在线事务的表永远不会达到速度显著变慢。
在 2023 年的今天，硬件的冲击让同样的事再次发生在分布式数据库上：可伸缩性（Scalability）和二十年前的 C10K 一样，成为了一个已解决的历史问题。如果推特这样的业务可以跑在单台服务器上，那么99.xxxx+ % 的业务终其生命周期，对可伸缩性的需求都不会超出这样一台服务器。这意味着这些大厂高P骄傲的“分布式”独门技术，在新硬件的冲击下沦为鸡肋 —— 如果今天还有人津津乐道什么分表分布式海量规模高并发，只能说明一件事：这哥们过去十年已经停止学习了，还活在上一个时代里。
Q：哦，你说的我知道，分布式数据库是要用分片ID去访问的
不想多说，我想任何稍微看过TIDB之类的newSQL介绍的人都会知道这个说法有多可笑，
另外由于newSQL的网络延迟原因，实际上newSQL（分布式分片方案）在线事务benchmark几乎无法超过单机数据库。
Q：说说缓存雪崩，缓存穿透，缓存击穿
首先咱的辣鸡业务确实没复杂到重度缓存的程度。
Q: 如何避免缓存雪崩
“你弄个好点的缓存机制不就好了吗”
Q: 那假如比如我的缓存设置的多少时间过期，要怎么避免雪崩
首先我们都知道对于八股的标准答案来说就是随机化过期时间，怎么说呢，对于缓存这种计算机科学中最困难的问题，你们保持一致性的方案居然是清一色的设定一个过期时间，如果这是真的将会再次刷新我对这个社会草台班子程度的认知。
为什么你们的机制不能是缓存永远不过期且和数据强一致呢？这样这些问题都不存在，难道你们的业务，全都能容忍缓存过期前的不一致性？尤其是某（很火的）Golang微服务框架，甚至把这个功能做进了框架里，令我大跌眼镜。
Q: Redis有哪些数据类型？
反正我真的不知道为什么对于KV数据库，还是一个辅助角色，会有人每种数据结构都去用。
Q: 这都是会用到的
是的，我没用到一定是因为太菜了
Q: MySQL迁移结构，会锁表吗，锁表了怎么办
“应该是会锁表，你搞几两个数据库做数据同步改了之后切换就行。”
然而我们在网上深入搜素之后发现，这个过程不一定锁表，还有一种叫Online DDL的东西可以在线迁移，于是我们又回到了数据库（或者我们现在集中于烂大街的MySQL）的锁机制问题，虽然这个东西可能异常的复杂（感觉可能DBA才会完全清楚）… 我们还是可以找到一些八股文。
我们发现这些东西居然有一个网站写的特别详细，排版也很好，点开他的首页，Solgan赫然写着“让天下没有难懂的八股文”，那么问题来了，究竟是谁为什么奉献了自己宝贵的时间，只为给我们贡献八股文的答案？翻到其中某一页，果然是卖课的…
我要笑死了，一口一个结合项目，请问答主为何经营公众号去了
总结
还不如做算法题，可惜没碰到几个会做的…
