Spanner 查询优化器版本

本页面介绍并提供了各种 Spanner 查询的历史记录 优化器版本。当前的默认版本为 6。 要详细了解查询优化器,请参阅查询优化器简介

Spanner 将查询优化器更新作为新查询发布 优化器版本。默认情况下,每个数据库在开始使用 优化工具在该版本发布 30 天后进行。

如果您使用 GoogleSQL 方言数据库,您可以管理查询优化器版本 查询使用的名称在提交到最新版本之前,您可以 在旧版本和最新版本之间查询性能配置文件。接收者 如需了解详情,请参阅管理查询优化器

查询优化器版本记录

下面总结了在每个版本中对查询优化器进行的更新。

版本 7:2024 年 5 月 22 日(最新)

  • 添加了对基于费用选择索引联合方案的支持。

  • 添加了对根据以下条件智能选择还原计划与扫描计划的支持 所有关键部分都没有可查找谓词的查询的统计信息。

  • 添加了对基于成本的哈希联接选择的支持。

版本 6:2023 年 9 月 11 日(默认)

  • 改进了通过全外联接的限制推送和谓词推送。

  • 改进了基数估算和费用模型。

  • 为 DML 查询启用了基于费用的优化。

版本 5:2022 年 7 月 15 日

  • 改进了索引选择、分布管理、排序的成本模型 和 GROUP BY 个所选展示位置。

  • 添加了对基于费用的联接算法选择的支持,可在 进行哈希处理并应用联接。合并联接仍需要使用查询提示。

  • 添加了对基于费用的联接交换的支持。

版本 4:2022 年 3 月 1 日

  • 改进了二级索引选择。

    • 改进了交错表之间的联接下的二级索引使用情况。
    • 改进了覆盖二级索引的使用情况。
    • 改进了优化器统计信息过时时的索引选择。
    • 首选在前导索引列上使用谓词的二级索引,即使是 如果优化工具统计信息不可用,或报告基表 非常小
  • 引入单传递哈希联接,由新提示启用 hash_join_execution

    联接提示:

    GoogleSQL

    SELECT ...
    FROM (...)
    JOIN@{join_method=hash_join, hash_join_execution=one_pass} (...)
    

    PostgreSQL

    SELECT ...
    FROM (...)
    JOIN/*@ join_method=hash_join, hash_join_execution=one_pass */ (...)
    

    哈希联接的构建辅助输入时,新模式非常有用 非常大。在以下情况下,一遍哈希联接预计可以实现更好的性能: 请查看查询执行配置文件中的以下内容:

    • 哈希联接的右侧子项上的执行次数较大 将大于哈希联接运算符的执行次数。
    • 哈希联接运算符的右侧子级的延迟时间也较长。

    默认情况下 (hash_join_execution=multi_pass),如果 哈希联接太大,无法存放在内存中,构建端被拆分为 我们可能会多次扫描探测端。使用 新模式 (hash_join_execution=one_pass),如果存在以下情况,哈希联接将溢出到磁盘: 其构建端输入无法存储在内存中,并且始终扫描探测器 一次。

  • 改进了选择用于跳转的键的数量。

版本 3:2021 年 8 月 1 日

  • 添加了一种新的联接算法——合并联接(通过使用新的 JOIN METHOD 查询提示值来启用)。

    语句提示:

    GoogleSQL

    @{join_method=merge_join}
    SELECT ...
    

    PostgreSQL

    /*@ join_method=merge_join */
    SELECT ...
    

    加入提示:

    GoogleSQL

    SELECT ...
    FROM (...)
    JOIN@{join_method=merge_join} (...)
    

    PostgreSQL

    SELECT ...
    FROM (...)
    JOIN/*@ join_method=merge_join */ (...)
    
  • 添加了一种新的联接算法——推送广播哈希联接(通过使用新的 JOIN METHOD 查询提示值来启用)。

    加入提示:

    GoogleSQL

    SELECT ...
    FROM (...)
    JOIN@{join_method=push_broadcast_hash_join} (...)
    

    PostgreSQL

    SELECT ...
    FROM (...)
    JOIN/*@ join_method=push_broadcast_hash_join} */ (...)
    
  • 引入了分布式合并并集 运算符(在适用时默认处于启用状态)。此操作 有助于提高查询性能

  • 当 SELECT 列表中没有 MAX 或 MIN 聚合(或 HAVING MAX/MAX)时,GROUP BY 下的扫描性能有小幅改进。在此更改之前,Spanner 加载了额外的非分组, 列,即使查询不需要该列。

    例如,请参考下表:

    GoogleSQL

    CREATE TABLE myTable(
      a INT64,
      b INT64,
      c INT64,
      d INT64)
    PRIMARY KEY (a, b, c);
    

    PostgreSQL

    CREATE TABLE myTable(
      a bigint,
      b bigint,
      c bigint,
      d bigint,
      PRIMARY KEY(a, b, c)
    );
    

    在此更改之前,以下查询将加载 c 列,即使查询不需要该列也不例外。

    SELECT a, b
    FROM myTable
    GROUP BY a, b
    
  • 当存在联接引入的 CrossApply 运算符且查询要求使用 LIMIT 对结果进行排序时,使用 LIMIT 提高可某些查询的性能。完成此更改后,优化器首先会应用针对 CrossApply 输入端施加限制的排序。

    示例:

    GoogleSQL

    SELECT a2.*
    FROM Albums@{FORCE_INDEX=_BASE_TABLE} a1
    JOIN Albums@{FORCE_INDEX=_BASE_TABLE} a2 USING(SingerId)
    ORDER BY a1.AlbumId
    LIMIT 2;
    

    PostgreSQL

    SELECT a2.*
    FROM albums/*@ force_index=_base_table */ a1
    JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
    ORDER BY a1.albumid
    LIMIT 2;
    
  • 通过 JOIN 推送更多计算来改进查询性能。

    推送更多计算,其中可能包括通过联接进行的子查询或结构体构造。这可以通过以下几种方式提高查询性能,例如: 能以分布式方式执行更多计算,执行更多运算 依赖于推送计算的容器也可以下推。对于 查询存在限制,而排序顺序取决于 计算,那么也可以通过联接推送此上限。

    示例:

    SELECT
      t.ConcertDate,
      (
        SELECT COUNT(*) FROM UNNEST(t.TicketPrices) p WHERE p > 10
      ) AS expensive_tickets,
      u.VenueName
    FROM Concerts t
    JOIN Venues u ON t.VenueId = u.VenueId
    ORDER BY expensive_tickets
    LIMIT 2;
    

版本 2:2020 年 3 月 1 日

  • 在索引选择中添加优化。
  • 提升了以下项下 REGEXP_CONTAINSLIKE 谓词的性能 。
  • 改进了某些情况下 GROUP BY 下的扫描性能。

版本 1:2019 年 6 月 18 日

  • 包括许多基于规则的优化,例如谓词下推、限制下推、冗余联接和冗余表达式移除等。

  • 使用用户数据统计信息来选择使用哪个索引来访问每个索引 表格。

后续步骤