Tidb server功能（2）
4.sql 语句的执行
解析好的执行计划给到 excutor ， excutor 去执行 执行计划。
复杂：
范 围查询、 join 、子查询、表连接、嵌套查询等等 ，走 distsql 模块 ，将对 tikv 复杂的请求封装起来，提供一个简单的方法。
最终呈现：转化成多个对单表的范围查询。
简单（点查）：
根据 主键索引、唯一索引 进行 等值 查询，查一行或零行的这种，走 KV 模块 。
点查（ KV ）和复杂查询（ distsql ）最终都会到 tikv client 。
tikv client 主要向 tikv 发送请求。
1.kv 这边来的
2.distsql 这边来的
如果有事务型的需求、对锁的管理，会从 executor 到 transaction ，进行两阶段提交。
事务需要在提交完后到 PD client （负责与 pd 交互）向 pd 申请 TSO 时间戳
5.online ddl 的执行
用户发起一个 ddl 语句，由 start job 接收，将这个 ddl 作为一个 job 放到对 tikv 的添加任务队列（ add index queue ）中。
多个 tidb server ，可以同时接收 ddl 语句，由各自的 start job 接收并放到对 tikv 的添加任务队列（ add index queue ）中。
tidb server 同一时间只有一个是 owner 角色， owner 只有一段时间，过期会重新选举。 owner 的 workers 模块负责对 job 队列（ job queue ）中区取第一个 job 执行，执行完后，把 job 放到历史队列（ history queue ）中，
schema load 模块 是成为 owner 之后，他会将最新的表 schema 的信息同步到内部缓存中，根据信息去执行 job queue 。
6. 垃圾（ gc ）回收
tidb 数据库对行操作进行更改操作，并不直接对数据进行更改，会记录下新的数据，并且打上时间戳。类似 oracle 的后映象机制（保留老的不变，但是有了更改后的后映象， oracle 不会打时间戳）。
定期清理就叫 gc 。
leader 角色的 tidb server 有 gc leader 。计算出 safe point ，在 safe point 时间前的历史数据清理。
gc life time=10m （默认 10 分钟） 所以一般 safe point 是 10 分钟。
清理过程：
找到过期的数据，看上面有没有锁信息，给你清掉，先 drop ，再 delete 之类的。
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/69980685/viewspace-3016985/ ，如需转载，请注明出处，否则将追究法律责任。
