# 物理优化的维度
![left](./student-guide/diagram/16-Dimension-of-Urbanization-01-01.png)
```
SELECT t1.a 
FROM t1 JOIN t2 ON t1.c1 = t2.c1 
ORDER BY t1.c1
```
-------------------------------------------------------------
物理优化为了解决在逻辑优化中按照规则优化后还存多种最优解，需要通过执行计划实际的 DataSource 算子决定，另外对于响应的物理机的配置以及负载有很大关系，理论上应该用最优资源解决最优的执行计划。

例如原 SQL 文本为 “select t1.a from t1 join t2 on t1.c1 = t2.c1 order by t1.c1;”，那么它的执行计划因为 Aggregation 算子对 “order by t1.c1” 可能会有 Sort 或者 NominalSort 两种方式，而后到了 Join 算子中对于 t1 和 t2 有 3 中 Join 方式，Hash join，Merge Join 或者 Index Join。在子算子层也会根据 Join 方式和 t1，t2 上面的索引情况，分别会有 Index Scan 或者 Table Scan 两种算子。这里不单单需要通过逻辑优化器进行规则优化，需要借助统计信息中对 Table 以及集群资源，负载的描述，来选择最优的执行计划来完成 SQL 请求。

物理优化器首先要根据统计信息的情况确认走索引还是全表扫描，一般情况会根据所描的行数/总行数，设置百分比触发索引扫描，高于这个值会走全表扫描。另外在选择索引时候，也会根据索引情况，比如符合索引前导列 distinct values 的统计个数来确认走哪个复合索引合适。另外需要将逻辑执行计划的已经构建的逻辑算子在物理优化器中实现，比如聚合算子 hash 算子或者 stream 算子，另外是 Join 算子的 hash join，index join 还是 merge join ，以及排序算子。

在逻辑优化器中提到的下推是下推到子节点计算。物理优化中也会考虑下推，这个下推指到在 TiKV 中的  coprocessor 模块中进行计算，目前支持的下推计算主要是聚合算子，Limit 算子以及 TopN 算子下推计算。