【 TiDB 使用环境】测试
【 TiDB 版本】V7.1.2
不同TiDB Server 上访问相同数据，是否需要到存储加载？
比如一个三个TiDB Server端的集群，一个程序连到TiDB server 1 访问了表T1并加载到TiDB server 1 的内存中，同时另外一个程序连到了TiDB Server 2也要访问表T1。假定此时T1全部在TiDB server 1 的内存中，那么TiDB Server 2也要访问表T1，这时数据是从TiDB Server 1传到TiDB Server 2 ，还是从TiKV中获取？
从TiKV中获取，tidb内存有限不可能存下太多表的数据，所以还要算子下推，在tikv上完成一些where筛选，聚合函数等，然后汇总到tidb处理
是的，会从TiKV中去拿
从tikv中获取
缓存表是缓存在每个tidb上吗
应该不是，要不你 trace 一下测一测 
第二个连接肯定从tikv中获取，因为第二个和第一个的tso不一样，不一样的tso意味着读取不同版本的数据。 
理论上内存加网络获取速度应该快于硬盘加网络，如果数据在第一个TiDB Server是最新的，我感觉从这个机器传过来性能会更好。
分布式数据库判断是不是新的有点难
这个缓存表真不咋好用，修改困难，速度也没快很多
你说的没错，所以怎么判断数据是最新的就是一个问题。
raft协议里面提到了两种做法，实现都在tikv，而不在tidb。
tidb之间并不会通信，无状态服务。
整个tidb的缓存设计也是多层的。tidb有缓存，tikv同样有。所以直接去tikv拿数据，按照raft的一套流程下来，和从另一个tidb拿效率其实是差不多的。
tidb-server之间是无感知的，所以不会相互传递
只有tikv里的数据是最新的，tidb里的无法判断是不是最新的。
肯定是TiKV,即使缓存表也是tidb server单节点
负责将 SQL 翻译成 Key-Value 操作，将其转发给共用的分布式 Key-Value 存储层 TiKV，然后组装 TiKV 返回的结果，最终将查询结果返回给客户端
节点之间完全对等
从另外tidb-server取还会有争用，像rac最大的问题就是gc争用
你讲到Oracle RAC的gc争用，其实这只是RAC的内容融合技术Cache Fusion的一个小问题。Cache Fusion扩展了基于shared-disk架构的信息交互方式，允许不同节点间通过interconnect网络共享数据库内部的buffer。数据直接从一个节点的buffer传递到其他节点，避免了读写共享盘。
它设计底层逻辑就是磁盘+光纤交换机的速度慢于内存+网络的速度。根本上是为了减少磁盘IO，提高性能，实践证明在多活架构中是比较稳定的。gc争用只是实现多活导致的一个性能问题，但不能否认它的价值。
当然ORACLE RAC是 shared-disk 的架构，TiDB是shared-nothing的架构，技术线路不同本身也不能直接对比。
我想问的是TiDB执行SQL的时候，想要获取region信息都是先从PD上访问，就是说它天然就知道region的分布情况，哪个是leader，哪个是follower，这样它是否也应该知道哪个region已经在哪个TiDB的Server 上了，如果是这样的话，TiDB是否也可以使用“内存融合技术”，减少磁盘IO，提高性能？
你的推测大致没错。
你问的这部分实现应该在client-go里面。
https://github.com/tikv/client-go
tidb就是用这个作为client来访问tikv。
client-go里面有一个region信息的缓存（region cache），所以client知道某个region大概在那个tikv上，当然也有被调度走的时候，如果调度走了。报错 region xxx is not leader，就会让对应id的region缓存失效，重新从pd上查询这个region的信息。
pd上的region信息都是节点上报的，需要知道tidb-server缓存了哪些region就需要tidb-server给pd上报缓存信息，但是tikv节点上本身也是有缓存的，从tikv节点获取最新的数据也是从内存获取的，所以tidb之间的“内存融合技术”感觉意义就不大了
tidb数据缓存主要靠tikv来缓存，tidb理论上知道数据在哪个tikv上，不同tikv数据不同，默认只查询leader的那个region