ITMO-Study-Note

主页/Lecture7/目录

Lecture 7: Выполнение запросов

讲座7：执行查询

1. Выполнение запросов и оптимизация 查询执行和优化

Повышение производительности запросов

提高查询性能

Способы повышения производительности запросов:
提高查询性能的方法:

• Использование индексов.
• 使用索引。
• Настройка физических параметров СУБД (способ разделения пространства хранения данных, стратегии работы с транзакциями и т. д.).
• 配置 DBMS 物理参数（数据存储空间分区方法、事务处理策略等）。

Выполнение запросов

执行查询

• 1. Разбор запроса (parser) → строится дерево 查询解析（解析器）→构建一棵树
• 1. Преобразование запроса (rewritter) 请求转换（改写）
• 1. Планировщик + Оптимизатор (planner) → план выполнения запроса 规划器 + 优化器（规划器） → 查询执行计划
• 1. Выполнение плана → executor 履行计划 → 执行

План выполнения запроса (query plan) 查询执行计划

• Чтобы выполнить SQL-запрос необходимо построить программу — план выполнения запроса.
• 要执行 SQL 查询，需要建立一个程序 - 查询执行计划。
• Таких программ может быть несколько.
• 这样的计划可以有好几个。
• 选最后效率最高的程序计划。

• 第一张图展示了查询执行流程。
  • 首先从表students开始，给出它这个表的判定条件（过滤），之后再与表exams进行连接，以他们之间的id相等作为连接条件，之后得出结果（ ==一般这种为最优解== ）
• 第二张图展示了另一种查询执行计划。
  • 首先直接将表students和表exams进行连接，之后再给出连接条件id，之后再给出他们的判定条件(group，id)，之后给出结果。

Конвейерная обработка данных 输送数据处理

• Конв. обр. данных — передача результатов одной операции на обработку другой без создания временных отношений (для хранения промежуточных результатов).
• 送数据处理–在不建立时间关系（用于存储中间结果）的情况下，将一个操作的结果转移到另一个操作的处理过程中。
• Для планов, в которых большинство операций происходят в конвейере:
• 适用于大部分操作都在传送带上进行的计划：
  • при расчете стоимости плана выполнения запроса отпадает необходимость в учете стоимости записи и последующего чтения промежуточных таблиц.
  • 在计算查询执行计划的成本时，无需考虑写入和随后读取中间表的成本。

Левосторонние деревья 左撇子树

• Левостороннее дерево — результат соединения - в левой части дерева, представляющего план.
• 树的左侧 - 连接的结果 - 位于代表计划的树的左侧。
• Внешнее отношение — слева.
• 外部关系是在左侧。
• Обычно оптимизаторы запросов в СУБД рассматривают только левосторонние деревья:
• 通常，数据库管理系统中的查询优化器只考虑左手树：
  • необходимо сократить число планов для анализа;
  • 有必要减少需要分析的计划数量；
  • такие планы позволяют избежать материализации, используя конвейерную обработку данных;
  • 通过使用数字数据处理管道来避免这些计划的实现；

Советы при построении плана 建立查询过程的一些建议

• Использовать конвейерную обработку (левосторонние планы, избегать блокирующих операций).
• 使用数字处理管道（左手计划，避免阻塞操作）。
• Делать выборку как можно раньше.
• 尽早取样。
• Делать проекции раньше.
• 提前进行预测。
• Грамотно планировать соединения.
• 巧妙规划连接。
• Цель: уменьшение размеров промежуточных данных => уменьшение числа операций чтения записи во внешнюю память
• 目标：减少中间数据的大小 => 减少外部存储器的读写操作次数

Индексы при построении планов 计划编制中的索引

• полезны:
  • выборка данных (фильтрация);
  • 数据取样（过滤）；
  • соединения;
  • 连接
• Негативные эффекты: 负面影响：
  • может потребоваться материализация промежуточных результатов.
  • 可能需要实现中间结果。

Расчет стоимости плана выполнения запроса 计算查询执行计划的成本

Можно выделить 3 основных составляющих:

• Чтение входных или промежуточных таблиц.
• 读取输入表或中间表
• Запись промежуточных данных (материализация — результат сохраняется во временных отношениях после выполнения одной операции для обработки следующей операцией).
• 记录中间数据（物化–一个操作完成后，将结果存储在时间关系中，供下一个操作处理）。
• Сортировка результата (DISTINCT).
• 对结果进行排序 (DISTINCT)。

2. Выполнение соединений 链接执行

• Реализации: 实现
  • Nested-loops join (NLJ)
  • 嵌套循环连接（NLJ）
  • Hash join (HJ)
  • 哈希连接 (HJ)
  • Sort-merge join (SMJ)
  • 排序合并连接（SMJ）

Nested-loops join (NLJ) 嵌套循环连接

• 工作方式是循环从一张表中读取数据(驱动表outer table)，然后访问另一张表（被查找表 inner table,通常有索引）。驱动表中的每一行与inner表中的相应记录JOIN。类似一个嵌套的循环。
• 对于被连接的数据子集较小的情况，嵌套循环连接是个较好的选择。在嵌套循环中，内表被外表驱动，外表返回的每一行都要在内表中检索找到与它匹配的行，因此整个查询返回的结果集不能太大（大于1 万不适合），要把返回子集较小表的作为外表（CBO 默认外表是驱动表），而且在内表的连接字段上一定要有索引。当然也可以用ORDERED 提示来改变CBO默认的驱动表。
• JOIN的顺序很重要，驱动表的记录集一定要小，返回结果集的响应时间是最快的。

Hash join (HJ) 哈希连接

• Hash join散列连接是CBO 做大数据集连接时的常用方式，优化器使用两个表中较小的表（通常是小一点的那个表或数据源）利用连接键（JOIN KEY）在内存中建立散列表，将列数据存储到hash列表中，然后扫描较大的表，同样对JOIN KEY进行HASH后探测散列表，找出与散列表匹配的行。
• 这种方式适用于较小的表完全可以放于内存中的情况，这样总成本就是访问两个表的成本之和。

Sort-merge join (SMJ) 排序合并连接

• Merge Join 是先将关联表的关联列各自做排序，然后从各自的排序表中抽取数据，到另一个排序表中做匹配。
• 因为merge join需要做更多的排序，所以消耗的资源更多。 通常来讲，能够使用merge join的地方，hash join都可以发挥更好的性能,即散列连接的效果都比排序合并连接要好。
• 如果行源已经被排过序，在执行排序合并连接时不需要再排序了，这时排序合并连接的性能会优于散列连接。

This site is open source. Improve this page.