Spanner 查询优化器版本 (original) (raw)
本页面介绍了各种 Spanner 查询优化器版本，并提供了相关历史记录。当前默认版本为 8。 如需详细了解查询优化器，请参阅查询优化器概览。
Spanner 会以新查询优化器版本的形式发布查询优化器更新。默认情况下，每个数据库在该版本发布后的 30 天内开始使用最新版本的优化器。
您可以管理 GoogleSQL 方言数据库和 PostgreSQL 方言数据库的查询所使用的查询优化器版本。在提交到最新版本之前，您可以比较旧版本与最新版本之间的性能配置文件。如需了解详情，请参阅管理查询优化器。
查询优化器版本记录
下面总结了在每个版本中对查询优化器进行的更新。
版本 8：2024 年 10 月 28 日（默认和最新）
- 在做出基于费用的方案选择时，系统会考虑
WITH子句。 - 改进了分布式交叉应用和索引查找查询的性能。
- 改进了
JOIN重新排序。 - 改进了包含大型
IN (...)子句的查询的性能。 - 改进了某些情况下的
GROUP BY性能。 - 其他改进，包括更高效地处理包含
LIMIT、外键和索引选择的查询。
版本 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 */ (...) 当哈希联接的 build 端输入很大时，新模式会很有用。如果您在查询执行情况分析中观察到以下情况，则一次通过哈希联接的性能可能会更好：
- 哈希联接右子级上的执行次数多于哈希联接运算符上的执行次数。
- 哈希联接运算符的右子级的延迟时间也很长。
默认情况下hash_join_execution=multi_pass，如果哈希联接的 build 端输入过大而无法存储在内存中，系统会将 build 端拆分为多个批次，我们可能会多次扫描探测端。使用新模式 (hash_join_execution=one_pass) 时，如果哈希联接的 build 端输入无法存储在内存中，则哈希联接会溢出到磁盘，并且始终只扫描探测端一次。 - 改进了选择用于跳转的按键数量。
版本 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 - 当存在联接引入的交叉应用运算符且查询要求使用 LIMIT 对结果进行排序时，使用
LIMIT可提高某些查询的性能。完成此更改后，优化器首先会应用针对交叉应用输入端施加限制的排序。
示例：
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_CONTAINS和LIKE谓词的性能。 - 改进了某些情况下
GROUP BY下的扫描性能。
版本 1：2019 年 6 月 18 日
- 包括许多基于规则的优化，例如谓词下推、限制下推、冗余联接和冗余表达式移除等。
- 使用有关用户数据的统计信息来选择要用于访问每个表的索引。