请教一下 TiDB 的同学 如何理解这段话呢？
“6.0 版本中对 RC 事务中的 SELECT 语句 TSO 请求做了优化，使用一种乐观方式获取 TSO ，仅当遇到新版本后才会获取最新的 TSO 读取数据，通过减少读操作从 PD 获取 TSO 的请求次数，从而降低查询延迟，提升读写冲突较小场景的 QPS。该特性由 tidb_rc_read_check_ts 变量控制，默认为 off，开启该功能设置为 on 即可。”
疑问：
1、这里版本指的是mvcc的版本，TiDB的事务采用了MVCC机制，当新写入的数据覆盖旧的数据时，旧的数据不会被替换，而是与新写入的数据同时保留，并以时间戳来区分版本。因此新旧的概念就是同一个数据的在不同时间点版本的新旧。因为这个机制的存在，所以读取数据时需要根据tso来保证一致性读取。
2、文章中表述的是RC事务中的select，并不是单纯的一个select语句。如果一个事务上来就select，那么tso就是start_ts，如果一个事务先update，然后再select，那么这个tso就是update的tso，而不是重新从PD获取新的tso。如果没有开启这个特性，那么事务中的select则需要再次从PD获取tso
不懂学习
2.1. ”如果一个事务上来就select，那么tso就是start_ts，“ 所以这种场景和文中描述的 延迟tso获取是无关的？
2.2:
begin;
update // commit_tso: 100
select * from t ; // 1， 一开始时 采用的 读取tso 是什么？ 2. 是否会在 ”遇到新版本， 再去获得一个新的读tso, 这个读tso 用于后续的 记录数的可见性判断 ?
感谢回复。
date 相关函数得出时间截。这个 算法 上没有太多技巧
1、新旧的标准就是看tso的大小，tso越大也就越新。
select的tso与数据的mvcc里的tso相比，如果select时的tso小于mvcc里的tso则重新从PD获取tso作为select的tso，而不使用之前语句的update_tso
2、
begin
//start_ts
update1 //update_ts1
update2 //update_ts2
select //默认使用update_ts2获取数据，如果发现数据存在更新(大于update_ts2)的版本，则到PD获取最新tso
…
commit //commit_ts
从问题中学习呀
刚看了看这个高级功能，我大概是这样理解的：
tidb 收到 select 的时候，不请求 ts， 用上一个 ts 向 tikv 发送，并且带一个标记：RcReadCheckTS，tikv 在扫描数据的时候，如果遇到了更新版本的数据，说明 ts 不合适，需要申请新的。给tidb返回 WriteConflict 错误。
tidb 如果还一条数据没发给客户端，那可以直接从pd获取个时间戳，再发送给 tikv 查询。如果tidb 已经发了一部分数据给客户端了，那发的数据就可能不符合隔离级别了，这次查询只能报错了。
这个方式适合数据冲突比较小的情况下。极端情况下假设你的数据根本都不变化，那tidb都不需要请求pd拿时间戳，直接访问tikv拿到数据返回即可，这样能降低不少的 tso 压力。
但是如果数据更新很频繁，每次去tikv读取都会遇到新数据，多折腾一次还浪费时间，增加延迟，那还是老老实实去pd 申请 tso吧。
tidb_rc_read_check_ts 是 TiDB 6.0 针对 RC 事务 SELECT 语句的 TSO 优化开关，默认关闭，开启后通过 “乐观获取 TSO” 减少 PD 请求；MVCC就是一个数据会有多个版本, 你这个时间点访问的可以继续用旧数据
date 相关函数得出时间截
TiDB 6.0 RC 事务 SELECT TSO 优化：默认用前序 TS，遇更大 MVCC 版本才取新 TS，降延迟提 QPS。
这是乐观锁?
这种优化,不知道会不会漏读数据,导致数据的不一致性读取呢
怎么开启呢
搞定了吗
这是个好问题，我也有同样的疑问。还有万一PD切换后的服务器时间真的与旧主机时间不同步的话会具体的处理逻辑会是怎样？
那就直接脑裂了,NTP要配好
关于这个问题，TiDB在处理TSO时的性能表现通常需要针对性优化。 期待更多的技术分享。