未使用主索引答案

【问题标题】：Primary Index not being used未使用主索引
【发布时间】：2021-11-15 13:17:33
【问题描述】：

我有一个具有以下规格的 greenplum 集群：

Master（16 个 VCPU，32GB RAM，27GB Swap）每个段有 4 个段（16 个 VCPU、62GB RAM、27GB 交换）

之前我有两个段，在我的用例中表现出色，但自从我将集群扩展到四个节点后，我无法让查询使用索引。

在 10 毫秒内执行的查询（索引命中）现在在顺序扫描中需要 2-5 秒。

我附上了我的架构和一些示例解释分析输出（这是一个示例查询计划，相关表中有 48260809 行）。

架构：

\c dmiprod
Create Table dmiprod_schema."package" 
(
    identity varchar(4096) not null,
    "identityHash" bytea not null,
    "packageDate" date not null,
    ctime timestamp not null,
    customer varchar(32) not null
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.package ADD CONSTRAINT "package_pkey" PRIMARY KEY ("identityHash");
create index idx_package_ctime on dmiprod_schema.package ("ctime");
create index idx_package_packageDate on dmiprod_schema.package ("packageDate");
create index idx_package_customer on dmiprod_schema.package ("customer");

CREATE TABLE dmiprod_schema."tags"
(
    "identityHash" bytea not null, 
    tag varchar(32) not null,
    UNIQUE ("identityHash",tag)
) distributed by ("identityHash");
create index "idx_tags_identityHash" on dmiprod_schema.tags ("identityHash");
create index idx_tags_tag on dmiprod_schema.tags ("tag");

CREATE TABLE dmiprod_schema."features"
(
    "identityHash" bytea not null, 
    ctime timestamp not null,
    utime timestamp not null,
    phash varchar(64) ,
    ahash varchar(64),
    chash varchar(78),
    iimages JSON ,
    lcert JSON ,
    slogos JSON
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.features ADD CONSTRAINT "features_pkey" PRIMARY KEY ("identityHash");
create index idx_features_phash on dmiprod_schema.features ("phash");


CREATE TABLE dmiprod_schema."raw"
(
    "identityHash" bytea not null, 
    ctime timestamp not null,
    utime timestamp not null,
    ourl TEXT,
    lurl TEXT,
    "pageText" TEXT,
    "ocrText" TEXT,
    html TEXT,
    meta JSON 
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.raw ADD CONSTRAINT "raw_pkey" PRIMARY KEY ("identityHash");


CREATE TABLE dmiprod_schema.packageLock
(
    "identityHash" bytea not null,
    secret bytea not null,
    ctime timestamp not null,
    UNIQUE ("identityHash")
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.packageLock ADD CONSTRAINT "packageLock_pkey" PRIMARY KEY ("identityHash");
create index idx_packageLock_secret on dmiprod_schema.packageLock ("secret");

【问题讨论】：

您是否在插入数据后更新了统计信息（分析）？

标签： optimization indexing greenplum

【解决方案1】：

重新创建表和索引，在identityHash 中插入 2000 万个 32、48、64、96 和 128 长度的随机字节，然后在使用 package_pkey 并在 20 毫秒内执行相同的选择结果。

除了索引的使用，另一个区别是 GPORCA 优化器的使用。我建议你set optimizer = 'on'; 再试一次。如果这不起作用，请发布您的 GPDB/Greenplum 版本和会话设置，包括优化器、enable_indexscan 和任何其他相关设置。

我在 VM 单物理主机和具有 4 个分段主机的 Tanzu Greenplum 6.17.1 上进行了测试。

【讨论】：

【解决方案2】：

只是为了确认：当您扩展系统时（假设使用 gpexpand），您确实运行了重新分配阶段（gpexpand 是一个两步过程）？完成后，您是否在系统上运行了 analyzeb 以确保使用新的表/索引段更新统计信息？

【讨论】：