Spanner 查询优化器版本

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

Spanner 将查询优化器更新作为新的查询优化器版本发布。默认情况下，每个数据库会在最新版本的优化器发布后的 30 天内开始使用该版本。

如果您使用的是 GoogleSQL 方言数据库，则可以管理查询使用的查询优化器版本。在提交到最新版本之前，您可以比较旧版本和最新版本之间的查询性能分析。如需了解详情，请参阅管理查询优化器。

查询优化器版本记录

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

改进了二级索引选择。
- 改进了交错表之间的联接下的二级索引使用方式。
- 改进了对二级索引用法的涵盖。
- 改进了优化器统计信息过时时的索引选择。
- 即使没有优化器统计信息或者报告基表很小，也优先使用对前导索引列具有谓词的二级索引。
引入了单卡券哈希联接，由新提示 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)，如果哈希联接的 build 端输入太大而不适合内存，那么 build 端会拆分为多个批次，并且我们可能会多次扫描探测端。采用新模式 (hash_join_execution=one_pass) 时，如果哈希联接的 build 端输入无法装入内存中，该哈希联接将溢出到磁盘，并且始终仅扫描探测端一次。
改进了选择使用多少个键进行跳转的功能。

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

语句提示：

@{join_method=merge_join}
SELECT ...

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

加入提示：

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

SELECT ...
FROM (...)
JOIN/*@ join_method=merge_join */ (...)

如果联接引入了交叉应用运算符，并且查询使用 LIMIT 请求已排序的结果，则使用 LIMIT 提高某些查询的性能。完成此更改后，优化器首先在交叉应用的输入端应用有限制的排序。

示例：

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

SELECT a2.*
FROM albums/*@ force_index=_base_table */ a1
JOIN albums/*@ force_index=_base_table */ a2 USING(singerid)
ORDER BY a1.albumid
LIMIT 2;