Rust 为了解决内存安全问题，引入了所有权系统。

所有的程序都必须和计算机内存打交道，如何从内存中申请空间来存放程序的运行内容，如何在不需要的时候释放这些空间，成了重中之重，也是所有编程语言设计的难点之一。在计算机语言不断演变过程中，出现了三种流派：

• 垃圾回收机制(GC)，在程序运行时不断寻找不再使用的内存，典型代表：Java、Go
• 手动管理内存的分配和释放, 在程序中，通过函数调用的方式来申请和释放内存，典型代表：C++
• 通过所有权来管理内存，编译器在编译时会根据一系列规则进行检查。

Rust 选择了第三种，最妙的是，这种检查只发生在编译期，因此对于程序运行期，不会有任何性能上的损失。

本篇是论文使用物化视图优化查询:一个实用的、可扩展的解决方案的中文简单翻译

查询语言是用户用来从数据库中请求信息的语言。查询语言可以分为过程化和非过程化的。在过程化语言中用户指导系统对数据库执行一系列操作以计算出结果。在非过程化语言中，用户只需要描述所需信息，而不用给出具体过程。

实际上使用的查询语言既包含过程化的成分，又包含非过程化的成分。在一些"纯"查询语言中，关系代数是过程化的，而元组关系演算和域关系演算是非过程的。

在解释关系代数操作之前，介绍一些基本概念：

• 关系：在关系代数中，关系是由行和列组成的表，以结构化格式表示数据。每个关系都有一个唯一的名称，并由元组组成。
• 元组：元组是关系中的一行，其中包含每个属性的一组值。它表示关系表中的单个数据条目或记录。
• 属性：属性是关系中的列，每个列表示数据的特定特征或属性。例如，在“学生”关系中，属性可以是“姓名”、“年龄”和“年级”。
• 域：域是属性可以具有的可能值的集合。它定义可以存储在关系的每一列中的数据类型，如整数、字符串或日期。

一些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 执行时进行调用。

蓄水池采样算法是一种随机抽样算法，它能够在一个很大的集合中，抽取一部分样本，并保证每个样本的选取概率都是相等并随机的。

• 特点：
  • 选取集合可以非常大，甚至不知道边界。
  • 每个样本的选取随机且概率相等。
  • 时间复杂度较低，O(n)，节省内存。
• 适用场景：
  • 在一些非常大的集合，或者未知大小的集合，不知道边界的集合，不知道文件总行数的情况下，随机抽取k个元素。
  • 保证每个元素抽取都是均匀随机的并且概率相等。
  • 尽量高效，节省内存地抽取

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

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

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

最近在日志中常常看到HikariCP的warnning.

Failed to validate connection com.mysql.jdbc.JDBC4Connection@xxxxx (...)Possibly consider using a shorter maxLifetime value.

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