此页面由 Cloud Translation API 翻译。

Spanner 查询优化器版本

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

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)，如果哈希联接的构建端输入太大而无法放入内存，系统会将构建端拆分为多个批次，并且我们可能会多次扫描探测端。在这种新模式 (hash_join_execution=one_pass) 下，如果哈希联接的构建端输入无法放入内存，则会溢出到磁盘，并且始终只扫描探测端一次。
改进了选择用于跳转的按键数量的功能。

添加了一种新的联接算法——合并联接（通过使用新的 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 */ (...)

添加了一种新的联接算法——推送广播哈希联接（通过使用新的 JOIN METHOD 查询提示值来启用）。

联接提示：

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

SELECT ...
FROM (...)
JOIN/*@ join_method=push_broadcast_hash_join} */ (...)

当存在联接引入的 CrossApply 运算符且查询要求使用 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;