YugabyteDB中LIKE查询索引优化问题解析

前言

在分布式数据库YugabyteDB的使用过程中，开发人员经常会遇到文本查询性能问题。本文将通过一个典型案例，深入分析YugabyteDB中LIKE查询的索引使用机制，解释为何某些情况下索引未被有效利用，并提供专业的优化建议。

问题现象

开发人员在YugabyteDB 2.25版本中创建了一个包含域名信息的表，并尝试使用LIKE查询进行前缀匹配：

CREATE TABLE domains (
    domain_id BIGSERIAL,
    domain_name VARCHAR(253) NOT NULL,
    PRIMARY KEY (domain_id),
    UNIQUE (domain_name)
);

当执行以下查询时，发现没有使用索引而是进行了全表扫描：

EXPLAIN (ANALYSE, dist, costs off)
SELECT domain_name
FROM domains
WHERE domain_name LIKE 'great%'
LIMIT 20;

问题分析

1. 默认哈希分片索引的局限性

YugabyteDB默认使用哈希分片（HASH）方式创建索引。这种索引类型在等值查询时表现良好，但对于范围查询或前缀匹配（如LIKE 'great%'）则效率低下。原因在于哈希索引将键值转换为哈希值存储，破坏了原始值的顺序性，无法支持高效的范围扫描。

2. 查询计划器的选择逻辑

当LIMIT值较小时（如20），查询计划器可能认为全表扫描比使用索引更高效。这是因为：

• 哈希索引不支持范围扫描，需要读取所有匹配项
• 对于小结果集，全表扫描可能确实更快
• 但当LIMIT增大到一定阈值（如198）时，计划器会重新评估并可能选择索引

3. 扩展索引方案的尝试

开发人员尝试了以下优化方案：

1. 添加pg_trgm扩展和GIN索引
2. 移除UNIQUE约束后单独创建B树索引
3. 强制禁用全表扫描（SET enable_seqscan = off）

其中，GIN索引在YugabyteDB中的支持尚不完善，特别是在处理大型数据集时可能遇到性能问题。

专业解决方案

1. 使用范围分片索引

正确的解决方案是创建范围分片（RANGE）索引：

CREATE INDEX domains_domain_name_asc ON domains(domain_name ASC);

这种索引保留了原始值的顺序性，可以高效支持前缀匹配查询。对于必须保持唯一性的列，可以先删除UNIQUE约束，再创建唯一性范围索引：

ALTER TABLE domains DROP CONSTRAINT domains_domain_name_key;
CREATE UNIQUE INDEX domains_unique ON domains(domain_name ASC);

2. 修改默认索引分片策略

可以通过配置参数永久改变默认索引分片方式：

yb-use-hash-splitting-by-default: false

这将使新创建的索引默认采用范围分片策略。

3. 查询优化建议

对于大型数据集（如10亿级别记录）：

• 避免使用GIN/trigram索引，因其在YugabyteDB中尚未完全优化
• 优先考虑范围分片索引
• 合理设置LIMIT值以影响查询计划器决策
• 定期执行ANALYZE更新统计信息

性能对比

优化前后性能差异显著：

• 哈希索引查询：约1400ms
• 全表扫描：约500ms
• 范围索引查询：约0.3ms

对于亿级数据表，这种差异将更加明显。

总结

YugabyteDB作为分布式数据库，其索引机制与传统PostgreSQL存在重要区别。开发人员需要特别注意：

1. 理解哈希分片与范围分片索引的适用场景
2. 对于文本前缀查询，必须使用范围分片索引
3. 大型数据集下需谨慎选择索引类型
4. 查询计划器的决策可能受LIMIT值影响

通过正确配置索引类型，可以显著提升LIKE查询等文本匹配操作的性能，特别是在超大规模数据环境下。