企业官网建设流程全解析

GaussDB索引实战：从‘商品销售表’案例看5种索引的正确用法与性能对比

电商平台的数据库查询性能直接影响用户体验和运营效率。想象一个典型场景：促销活动期间，后台系统需要同时处理商品详情页的频繁访问、订单状态的实时查询、多条件筛选的热销商品列表，以及销售金额的区间统计报表。这些操作如果缺乏合理的索引设计，轻则导致页面加载缓慢，重则引发数据库连接池耗尽。本文将以一个商品销售表为例，演示如何针对五种典型查询场景选择最佳索引策略。

1. 高频商品查询与普通索引优化

商品详情页是电商平台访问量最大的页面之一。假设我们有一个包含500万条记录的商品销售表sell_info_full，其中goods_id字段记录了商品唯一编码。当用户频繁通过商品ID查询销售记录时，没有索引的全表扫描将成为性能瓶颈。

-- 未创建索引时的查询 EXPLAIN ANALYZE SELECT * FROM sell_info_full WHERE goods_id = 'G10086';

执行计划显示Seq Scan（顺序扫描），耗时约320ms。这时创建一个普通B-tree索引能显著提升查询速度：

CREATE INDEX idx_goods_id ON sell_info_full(goods_id);

创建后再次执行相同查询，执行计划变为Index Scan，耗时降至8ms。但需要注意：

普通索引适合高区分度字段。如果goods_id只有几十个不同值（如商品类别而非具体商品），索引效果会大打折扣。

2. 订单唯一性保障与唯一索引实践

订单系统的核心要求是每个sell_id必须绝对唯一。虽然主键约束已经确保唯一性，但显式创建唯一索引有额外优势：

CREATE UNIQUE INDEX idx_unique_sell_id ON sell_info_full(sell_id);

与普通索引相比，唯一索引：

在业务逻辑上，唯一索引可以作为"防重放"机制。例如防止同一订单被错误地重复处理：

-- 重复插入会报错 INSERT INTO sell_info_full VALUES (1001, '2023-08-01', 'G10086', '智能手机', 1, 5999, '2023-08-01');

3. 多条件组合筛选与复合索引设计

运营人员经常需要组合查询，例如"查询销量大于100且金额超过5000元的商品"。针对这种场景，多字段索引比单字段索引更高效：

CREATE INDEX idx_goods_amount_number ON sell_info_full(sell_goods_amount, goods_number);

关键设计要点：

• 字段顺序原则：将区分度高的字段放在前面。如果sell_goods_amount有1000个不同值，goods_number只有10个，现有顺序更优
• 覆盖索引：如果查询只涉及索引字段，可以避免回表操作

-- 能充分利用复合索引的查询 EXPLAIN ANALYZE SELECT goods_id FROM sell_info_full WHERE sell_goods_amount > 5000 AND goods_number > 100;

4. 热销商品分析与部分索引妙用

电商大促期间，运营往往只关注头部热销商品。为这类高频查询创建全表索引会造成存储浪费，此时部分索引(Partial Index)是理想选择：

-- 只为销量前10%的商品创建索引 CREATE INDEX idx_hot_goods ON sell_info_full(goods_id) WHERE goods_number > (SELECT percentile_cont(0.9) WITHIN GROUP (ORDER BY goods_number) FROM sell_info_full);

这种索引的特点是：

• 存储空间节省：只索引满足条件的行，体积比全表索引小80%
• 维护成本低：数据变更时只对符合条件的行更新索引
• 自动失效：当商品销量跌出阈值范围，会自动移出索引

5. 金额区间统计与表达式索引应用

财务报表经常需要按金额区间统计，如"查询金额在100-200元之间的订单数"。直接对sell_goods_amount创建索引无法优化这类范围查询，但表达式索引可以：

CREATE INDEX idx_amount_range ON sell_info_full((sell_goods_amount/100));

这样优化后，以下查询可以利用索引：

-- 查询金额在100-200元之间的订单 SELECT COUNT(*) FROM sell_info_full WHERE (sell_goods_amount/100) BETWEEN 1 AND 2;

表达式索引的注意事项：

1. 确保表达式与查询条件完全匹配
2. 复杂表达式可能增加索引维护开销
3. 常用场景：日期截取、数学计算、字符串处理等

6. 索引管理实战技巧

创建索引只是开始，日常管理同样重要。分享几个实用技巧：

查看索引使用情况：

SELECT * FROM pg_stat_user_indexes WHERE relname = 'sell_info_full';

识别无用索引（三个月未被使用）：

SELECT schemaname, relname, indexrelname FROM pg_stat_user_indexes WHERE idx_scan < 50 AND schemaname = 'public';

索引维护最佳实践：

• 在业务低峰期创建大型索引
• 定期执行ANALYZE更新统计信息
• 监控索引膨胀率，适时REINDEX

# 检查索引膨胀率 SELECT nspname || '.' || relname AS table, indexrelname AS index, pg_size_pretty(pg_relation_size(i.indexrelid)) AS index_size, idx_scan as scans FROM pg_stat_user_indexes i JOIN pg_index x ON i.indexrelid = x.indexrelid JOIN pg_class c ON c.oid = i.relid JOIN pg_namespace n ON n.oid = c.relnamespace WHERE (pg_relation_size(indexrelid) > 1024*1024);

7. 真实场景性能对比测试

为了直观展示不同索引的效果，我们在测试环境模拟了1000万条商品销售记录，对比五种典型查询在有/无索引时的性能差异：

测试中发现的几个有趣现象：

1. 当查询结果超过表记录的30%时，索引扫描反而比全表扫描更慢
2. 复合索引中字段顺序错误会导致性能下降50%以上
3. 表达式索引对模糊查询优化效果显著，如WHERE upper(goods_name) LIKE 'PHONE%'

在一次618大促前的压力测试中，合理配置索引使数据库QPS从原来的1200提升到6500，同时CPU负载从90%降至45%。这个案例充分证明了"索引是性价比最高的优化手段"这一经验法则。