那就是的
文档里有一段关于rc的select tso优化，其他的细节没有查到
网上找到的内容，看起来比较详细。
TiDB中的TSO（Timestamp Oracle）是一个由PD（Placement Driver）Leader节点分配的全局单调递增的时间戳，用于实现分布式事务的MVCC（多版本并发控制）。TSO由两个主要部分组成：
- 物理时间（Physical Time）：
- 物理时间部分占用了TSO的高位（通常是高48位），表示自Unix纪元（1970年1月1日）以来的毫秒数。这一部分用于表示时间戳的实际时间信息。
- 逻辑时间（Logical Time）：
- 逻辑时间部分占用了TSO的低位（通常是低18位），是一个数值计数器，用于在同一物理时间下区分不同的时间戳。当物理时间没有变化时，通过增加逻辑时间可以生成多个不同的TSO。
TSO的生成与分配：
- PD Leader节点负责生成和分配TSO。它会在内存中维护一个时间窗口，该窗口包含了当前时间和未来一段时间内可分配的TSO。
- 当TiDB的客户端或组件需要TSO时，它们会向PD Leader节点发送请求。PD Leader节点会从其维护的时间窗口中分配一个TSO，并返回给请求者。
- 为了保证TSO的单调递增和持久化，PD节点会将时间窗口的起始和结束时间戳持久化到etcd中。这样，即使PD节点发生故障或重启，也能从etcd中恢复最新的TSO状态，确保TSO的连续性和一致性。
TSO的作用：
- 在TiDB中，事务的开始（start_ts）和提交（commit_ts）都会使用TSO来标记时间戳。这两个时间戳用于实现事务的MVCC，确保事务的隔离性和一致性。
- TSO的单调递增性保证了事务之间的顺序性，即先开始的事务的start_ts一定小于后开始的事务的start_ts，这有助于解决分布式事务中的并发冲突和版本控制问题。
综上所述，TiDB中的TSO是由物理时间和逻辑时间两部分组成的，它通过PD Leader节点的集中分配和etcd的持久化机制，确保了全局一致性和单调递增性，为分布式事务的MVCC提供了关键的时间戳支持。
不需要
Select会不会有特殊的流程过去tso？毕竟查询最频繁
从自然时间到tso的转换，可以参考这个帖子。
其实就是毫秒时间（物理时间戳）转2进制，拼18位2进制（逻辑时间戳），再把拼好的2进制数字，从2进制转到10进制，就是显示出来的tso。
因为一个逻辑时间戳有18位2进制，所以逻辑时间戳的大小是2^18=262,144.
TSO是一个 int64的整数型，主要是由 physical (unix时钟，精确到毫秒) 和 logical (逻辑相对时钟) 组成，TSO的分配都是由PD集群中的 Leader 节点 分配的。TiDB Server 在请求PD 获取 TSO的时候是调用Leader节点，通过异步 callable-future 的方式获取的，避免了PD生成TSO的等待时间。
还需要注意一点的是， PD在分配TSO的时候会对TSO进行落盘，即会产生IO操作，所以在分配过程中会分配 一段时间窗口 的TSO并缓存到内存，在TiDB Server 多次获取的过程中，只需要从内存中获取TSO即可，大大增加了并发性。源码在 pd 的
pkg/tso/global_allocator.go
1 个赞
官方已经写了，考试也考过哦。
哈哈，nnd
物理时钟+逻辑时钟
这个多次考试中出现过哦，
物理+逻辑时钟
物理、逻辑时钟
来个结帖功能吧
好关闭了
物理+逻辑
肯定是物理时钟+逻辑时钟哦。
学习了
物理时钟+逻辑时钟