在官方文档中，有如下一段描术：
场景二：在部分跨数据中心部署的场景中，如果使用了强一致性的 Follower 读，为了读到的数据与 Leader 上的数据一致，会产生跨数据中心获取 Readindex 来校验的请求，导致整体查询的访问延迟增加。通过使用 Stale Read 功能，可以牺牲一定的实时性，就近访问对应数据所在当前中心的副本，避免跨数据中心的网络延迟，降低整体查询的访问延迟。
我的观点
我对在跨数据中心采用Stale Read效率会比Follower Read高，产生很大的怀疑，在我看来，Stale Read的效率被事务的执行时长影响严重，是个对应用开发者很不友好的方案。而Follower read不受事务执行时长的影响，主要取决于基础设施网络层、磁盘IO等处理速率的影响，应该说它是一个更加健壮的方案，我们在遇到效率问题时，可以通过改进基础设施来完全解决跨数据中心读取延迟高的问题，而如果采用Stale Read，你永远不知道下一次什么时候会遭遇严重的读取延时
我对两个方案的理解：
Stale read 需要确保读取时间小于safe_ts时间，而safe_ts需确保在此之前的事务全部已提交。也就是Stale read需要等待任何在它之前已经开始执行的事务的提交。所以它深受业务层的事务时长影响。我认为一个健壮的系统，即时没办法100%做到不受上层的影响，也应该尽可能将这种影响最小化。
而Follower read是等待Follower APPLY_INDEX要大于读取时的Leader READ_INDEX，这跟在它前面的事务是否已经提交无关。它只要确保读取到的数据是在它之前已经提交的最新数据即可，这符合MVCC的标准行为。它的延迟取决于基础设施的性能以及TiDB本身的同步算法。完全不受上层事务长短的影响。显然是个更可取的方案。如果有瓶颈，我认为应该优先考虑提升基础设施，而不是优先采用Stale Read方案
简单总结：
我认为Stale Read方案更加不可控，它的效率完全受上层业务的影响，而Follower Read方案更加可控，它只取决于底层的处理能力，不容易反向受制于上层。