一些SQL构造（如ORDER BY）在许多情况下不会影响查询结果，并且会产生影响性能的负面影响(查询中的每个ORDER BY子句都代表一个排序执行计划)。如果用户无意中在没有效果的地方使用ORDER BY，可能会导致严重的性能下降和资源浪费。

sql规范(ISO 9075 Part 2)中说明:

• 一个<query expression>可以包含一个可选的<order by clause>。
• <query expression>z中行的顺序仅由<query expression>直接包含的<order by clause>指定。

上述规范意味着，查询引擎可以自由地忽略任何不适合上下文的ORDER BY子句。

Presto Functions 并不能像 Hive UDF 一样动态加载，需要根据 Function 的类型，实现 Presto 内部定义的不同接口，在 Presto 服务启动时进行注册，然后才能在 SQL 执行时进行调用。

Trino中的内存管理分为两块:

• LocalMemoryManager: 在ServerMainModule中声明，用于管理当前节点的内存使用
• ClusterMemoryManager: 在CoordinatorModule中声明，用于管理集群的内存使用

上篇我们介绍了查询是如何调度的。本篇将介绍Task的执行。

上篇分析了SQL逻辑执行计划的生成，本篇将继续分析逻辑计划是如何在进行调度的。

Trino在查询提交时，会将SQL文本解析成语法树。Trino将这一动作分为2个部分:

flowchart LR
    s1(SQL)-->|Parser base Antlr|s2(ANTLR AST)
    s2-->|AST builder base Antlr Visitor|s3(Presto AST)

上篇分析了trino提交查询部分的源码，本篇来分析下，构建执行计划部分的源码。

本篇来看下在查询执行的过程中，底层的数据结构是什么样的。

上篇介绍了Trino的启动流程，这篇我们来学习下查询提交的流程。

本篇文章开始，我们将进行Trino的源码分析，一切还是从启动开始看起。