Cloud Spanner 在不应该使用的时候使用了二级索引

Question

使用主键快速执行的现有查询在没有通知的情况下大幅减慢（10 毫秒 -> 8 秒），因为现在自动使用为另一个用例创建的二级索引。

Cloud-Spanner-Web-Query的'Explanation'告诉我使用了二级索引。如果我更改顺序（仅用于测试目的）或提供 FORCE_INDEX 查询再次快速。

我可以 'fix' 这个问题，方法是使用 FORCE_INDEX=_BASE_TABLE，在 Cloud Spanner Query Syntax Documentation.

我的问题是：我真的必须为每个查询执行此操作以避免此类影响吗？

这混合了查询定义和索引定义，恕我直言，这不是一件好事。

Table 主索引：

CREATE TABLE change_history (
    userId INT64 NOT NULL,
    createdAtUnique INT64 NOT NULL,
    itemId STRING(512) NOT NULL,
    newValue FLOAT64 NOT NULL,
    oldValue FLOAT64 NOT NULL,
) PRIMARY KEY (userId, itemId, createdAtUnique DESC)

二级索引：

CREATE INDEX ch_userid_createdatunique_all ON change_history (
    userId,
    createdAtUnique
) STORING (
    newValue,
    oldValue
)

原查询：

SELECT * FROM change_history WHERE                         
    userId = 2563
    AND itemId = "215414"
    AND createdAtUnique >= 15385766670000000
    AND createdAtUnique <= 15465254670000000 ORDER BY createdAtUnique

我希望查询继续使用它设计的主键。

但是通过添加二级索引，查询开始使用二级索引而不是主键。

Answer 1

在这种情况下，查询优化器决定选择索引，因为 1) 它正在覆盖，并且 2) 避免了原始计划中的排序，因为索引包含 createdAtUnique 的升序排序，这是排序查询中请求的订单。但是，对于您的数据分发，这被证明是一个糟糕的选择。

一般来说，对于手动调整的查询以获得您知道的特定计划 optimal/good，最好使用 force_index 和 join_type 提示查询以防止优化器可能选择不同计划的罕见情况。

Cloud Spanner 在不应该使用的时候使用了二级索引

Cloud Spanner is using a secondary index when it should not

google-cloud-platform

google-cloud-spanner