这个问题跟隔离等级并没有什么关系，各个数据库对不同隔离级别到底能避免哪些 phenomenon 表现并不一致，合乎 ANSI 的标准即可。
对于”不存在的数据“上锁，只是一些 lock-based 的数据库为了避免 Phantom 这样实现的罢了，ANSI 标准本身并没有规定到底怎么样避免 phantom..
另外 gap 锁这个东西相当不好控制，很容易掉坑里造成大面积的事务死锁...
这个场景本身就带很强的业务属性，为什么不可以依赖业务逻辑来保障呢？

dalao 有空瞅一下知乎私信哈😹

1. 调整好心态，继续面试
2. MT 白菜价肯定够在北京生活...3000 可以在 SOHO 附近住还行的单间了，可以骑车上班 =-= 我 2500 租的

头像可以的 蕉♂燥

不适合 TiDB，考虑时序数据库（ TDengine 最近好像挺火=-=没实际用过）或者专门的 AP 引擎都行

<dependency>
<groupId>uk.com.robust-it</groupId>
<artifactId>cloning</artifactId>
</dependency>

233，才在 qq 空间看到别人转发

sharding-proxy 的话，试试 YouTube 的 vitess 吧

P8 都能在北京扎根了...为啥要回长沙...

@my2019edc 戾气太重了，美团开源的东西并不少，Cat，Zebra，Octo，mpvue 等等，反哺社区的我知道的也有 Doris、Kylin、TiDB 这些

@winoros 嗯，不是说冲突，是猜着应该是要在标准 mysql protocol 上面做扩展了，比如指定哪些表需要列存，指定分区键，表之间会带上依赖关系这种...最后还是没走 PAX 啊，资源隔离这个问题没搞好

点个赞，谈到的问题基本上全都碰上了..
个人有几个小问题
1. 回到 AP 的场景，从文章里面看到的东西还是很多疑问，比如说楼上提到的 learner 转列存的...听起来很美好，但是 AP 追求的就是扫描性能，避免 shuffle，要有 co-located join，继续那一套标准的关系型数据模型行不通的，这个是怎么解决的呢，在建表的时候要额外带些信息？
2. 热点调度全球首创这个...Spanner 里面不是 PlacementDriver 也干这个活吗，是有什么很特殊的创新点吗？
3. 有的时候我会觉得 TiDB 的 Raft 这一层是不是做得太底了，Spanner 里面的 Paxos-group 在 Tablet 上面，粒度很大，这样一个是大部分时候都是走的 1PC，另外也不会出现几万数十万个 Raft-Group 弄得某个 KV 在处理这一块压力很大的情况
4. 其实实际使用的时候，资源浪费还是比较严重，很多业务不需要那么高的 HA，是不是也可以跟 Spanner 一样，搞 Witness 那种可选的部署类型，提升 Quorum 的速度？

当项目中不止 java 的时候就不该用了...比如混入了 groovy，不过大部分人吃不到这个亏..
仁者见仁智者见智吧，单纯自己玩的时候会用一下，但是团队合作会避免

@vjnjc 抱歉回复得晚了，最近比较忙..
对于存储引擎的选项来说，核心是从业务场景出发：
1. 数据应用层的类型到底是 OLTP （高频点查，明显的特征就是查询走索引，关心明细数据）还是 OLAP （指标分析类、海量数据聚合，关注扫描性能）
2. 冷热数据分离，数据量在持续增长，但如果其实有大量冷数据，没必要一直放在关系型数据库中，归档至 HIVE 也是不错的选择，即使临时碰到了需要查询的场景，不过是慢一些而已
3. 对可用性的要求是不是真的有那么高，其实 MySQL+MHA 的可用性也很高了，不是金融行业，挂个 30~60s 也能接受吧

下面再来结合谈谈 TiDB 本身：
1. TiDB 目前 OLAP 是不能看的，TiSpark 优势比起其他的传统 AP 没有啥优势，他们最近也在基于 Clickhouse 做新的一个 AP 引擎 TiFlash，不过稳定估计还是要过很长一段时间了....
2. 不考虑异地多 IDC 的情况，TiDB 的可用性并不一定比传统的 MySQL+MHA 好很多，如果 KV 层挂一个 node，其实也会有 60s （具体看配置，但肯定不会少于 15s ）左右的部分查询写入失败；
3. 小坑会比较多（一般都是参数配置相关的）...这个也没法具体展开讲，但核心就是碰到了问题网上资料会很少，你需要与官方去沟通，官方比较活跃的，但这个时间比起能在网上找到肯定长很多....所以最好要有相关的知识储备，它复杂的架构不是一般开发能 cover 住的，多达 700 多个监控指标...所以运维门槛比较高
4. 成本，这个就不多谈了
5. 很关注读写延迟就不用考虑用这个了

其实现在 sharding-proxy 的框架挺多的，tddl、zebra 等等，10 亿的数据量做 sharding 也还好
对于 NewSQL 除了强大的 scale-out 能力外，还有一个优势就是分布式事务
可以结合自身的实际情况尝尝鲜，先从非核心业务慢慢迁移和熟悉，后面自己心里应该就有答案了

这个数据量不建议上 TiDB，成本太高了，overkill
其实不涉及到复杂 SQL 偏 AP 的查询，纯粹的点查即使 MySQL 存储 4~5 亿行的数据也能良好工作
磁盘务必 SSD 这个观点很奇怪...这个是与你使用数据库的底层数据结构强相关的
我有负责过组内每天过 TB 吞吐和单表百亿行的场景到 TiDB，TiDB 有他的好，也有他的坏，我个人还是很喜欢这个数据库，也看好他，不说实话实说，目前这家的坑不少，不要盲目追求新的技术（ NewSQL ），适合自己最好

1.选 he 举 xie 完并不能保证 follower 和 leader commit logs 一致，保证的是如果某个日志条目在某个 term 中已经被提交，那么这个条目必然出现在更大 term 的所有 leader 中
2. 读必须走 leader，最原始的 logRead 还需要落一次盘，indexRead 才可以不落盘，leaseRead 不用走 raft-roundtrip，但也还是需要读 leader。所以单 raft 读也无法 scale-out
3. multi-raft 可以做读写的 scale-out

@hilbertz 摆配置吧，TiDB 本来追求的就是吞吐不是 latency，还可以 scale-out