代码之家  ›  专栏  ›  技术社区  ›  Christian Gintenreiter

云扳手在不应该使用辅助索引的情况下使用辅助索引

  •  1
  • Christian Gintenreiter  · 技术社区  · 6 年前

    由于为另一个用例创建的辅助索引现在被自动使用,因此使用主键快速执行的现有查询速度大大减慢(10毫秒->8秒),而不另行通知。

    云扳手Web查询的“解释”告诉我使用了辅助索引。如果我更改了顺序(只是为了测试目的)或提供强制索引,查询将再次快速进行。

    我可以用 force_index=_base_表 记录在 Cloud Spanner Query Syntax Documentation .

    我的问题是:为了避免这种影响,我真的必须对每个查询都这样做吗?

    这将查询定义和索引定义混合在一起,这不是一件好事。

    带主索引的表:

    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
    

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

    但是通过添加辅助索引,查询开始使用这个索引而不是主键。

    1 回复  |  直到 6 年前
        1
  •  4
  •   adi    6 年前

    在这种情况下,查询优化器决定选择索引,因为1)它正在覆盖索引,2)在原始计划中避免排序,因为索引包含 createdAtUnique 按升序排序,这是查询中请求的排序顺序。然而,对于您的数据分发来说,这是一个糟糕的选择。

    一般来说,对于手动调整以获得最佳/良好的特定计划的查询,最好使用 force_index join_type 查询中的提示,以防止优化器可能选择其他计划时出现罕见的实例。