在Cloud Spanner中对INTERLEAVE二级索引使用STORING子句有什么好处？

Question

如果我们使用带有二级索引的Interleave选项，使用存储子句还有好处吗？

https://cloud.google.com/spanner/docs/secondary-indexes

Answer 1

是的，虽然不太可能成为主要的好处，但仍然可以带来好处：

假设你有交错的表格Singers-＆gt; Albums-＆gt; Songs，你有一个索引：

CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
    INTERLEAVE IN Singers

我们还假设Songs有一个FLOAT64列，LengthInSeconds，用于存储歌曲的长度。

如果您想要查找以“T”开头且长度不到4分钟的SingerId 123的所有歌曲，您的查询可以通过以下方式执行：

1. 使用SongsBySingerSongName查找歌手123的所有歌曲 以“T”开头
2. 对于这些歌曲，请使用Songs重新加入 查找LengthInSeconds按长度过滤。

由于Songs和SongsBySingerSongName都在Singers表中交错，我们知道我们的数据应该都在同一个split中，这意味着它们都会驻留在同一台机器上，这意味着步骤（2）中的反向连接将不会非常昂贵。但是，本地反向连接仍然需要花费查找数据的成本，因此通过使用STORING子句来保存步骤（2）仍然可以减少查询延迟和总体成本。您可能希望对工作负载进行基准测试，以查看额外存储子句是否提供了净收益。

通常，如果查询中的过滤器引用了索引中的列（键列或“存储”列），则可以在对基表进行反向连接之前评估过滤器，如果过滤器不匹配，可以避免反向连接。如果过滤器引用不在索引中的列，则必须首先执行反向连接以获取过滤器引用的列值