postgresql----索引失效

最新推荐文章于 2025-06-22 16:09:12 发布
最新推荐文章于 2025-06-22 16:09:12 发布
阅读量701 收藏 1
点赞数
CC 4.0 BY-SA版权
文章标签： 数据库
原文链接：http://www.cnblogs.com/alianbog/p/5648455.html
本文探讨了数据库中索引失效的多种情况，包括计算、函数调用、类型转换、使用!=或NOT、模糊查询、索引字段占比高、多字段索引使用不当及使用OR等情况，并通过实际测试案例进行了说明。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

什么是索引失效？如果where过滤条件设置不合理，即使索引存在，且where过滤条件中包含索引列，也会导致全表扫描，索引不起作用。什么条件下会导致索引失效呢？

1.任何计算、函数、类型转换

2.!=

3.NOT，相当于使用函数

4.模糊查询通配符在开头

5.索引字段在表中占比较高

6.多字段btree索引查询条件不包含第一列

7.多字段索引查询条件使用OR（有时也会走索引扫描，但查询效率不高）

 

测试表

test=# \timing 
Timing is on.
test=# create table tbl_index(a bigint,b timestamp without time zone ,c varchar(12));
CREATE TABLE
Time: 147.366 ms
test=# insert into tbl_index select generate_series(1,10000000),clock_timestamp()::timestamp without time zone,'bit me';
INSERT 0 10000000
Time: 30982.723 ms

 

1.任何计算、函数、类型转换

crtest=# create index idx_tbl_index_a on tbl_index (a);
CREATE INDEX
Time: 19634.874 ms
test=# 
test=# explain analyze select * from tbl_index where a = 1;
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_a on tbl_index  (cost=0.43..8.45 rows=1 width=23) (actual time=59.844..59.850 rows=1 loops=1)
   Index Cond: (a = 1)
 Planning time: 22.788 ms
 Execution time: 60.011 ms
(4 rows)

Time: 84.865 ms
test=# explain analyze select * from tbl_index where a + 1 = 1;
                                                           QUERY PLAN                                                            
---------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..84399.00 rows=50000 width=23) (actual time=7678.109..7678.109 rows=0 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on tbl_index  (cost=0.00..78607.33 rows=20833 width=23) (actual time=7350.047..7350.047 rows=0 loops=3)
         Filter: ((a + 1) = 1)
         Rows Removed by Filter: 3333333
 Planning time: 0.112 ms
 Execution time: 7688.615 ms
(8 rows)

Time: 7780.024 ms
test=# explain analyze select * from tbl_index where power(a,2) = 1;
                                                           QUERY PLAN                                                            
---------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..94815.67 rows=50000 width=23) (actual time=47.516..6902.399 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on tbl_index  (cost=0.00..89024.00 rows=20833 width=23) (actual time=4607.894..6892.174 rows=0 loops=3)
         Filter: (power((a)::double precision, '2'::double precision) = '1'::double precision)
         Rows Removed by Filter: 3333333
 Planning time: 13.564 ms
 Execution time: 6904.232 ms
(8 rows)

Time: 7051.482 ms
test=# 
test=# explain analyze select * from tbl_index where a::varchar = '1';
                                                           QUERY PLAN                                                            
---------------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..94815.67 rows=50000 width=23) (actual time=1.239..6689.272 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on tbl_index  (cost=0.00..89024.00 rows=20833 width=23) (actual time=4449.890..6679.233 rows=0 loops=3)
         Filter: (((a)::character varying)::text = '1'::text)
         Rows Removed by Filter: 3333333
 Planning time: 1.029 ms
 Execution time: 6692.329 ms
(8 rows)

Time: 6723.530 ms

 

在表tbl_index.a字段创建btree索引，使用a=1索引生效，但是下面的例子运算、函数、类型转换却导致索引失效了。

where a + 1 = 1

where power(a,2) = 1

where a::varchar = '1'

如何解决呢？可参考前面的表达式索引解决：

create index idx_tbl_index_a on tbl_index ((a+1));

create index idx_tbl_index_a on tbl_index ((power(a,2)));

create index idx_tbl_index_a on tbl_index ((a::varchar));

 

2.!=

test=# explain analyze select * from tbl_index where a != 1;
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=0.00..140899.00 rows=9999999 width=23) (actual time=0.049..11004.864 rows=9999999 loops=1)
   Filter: (a <> 1)
   Rows Removed by Filter: 1
 Planning time: 0.206 ms
 Execution time: 11585.859 ms
(5 rows)

Time: 11587.146 ms

 

3.NOT，相当于使用函数

test=# explain analyze select * from tbl_index where a is null;
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_a on tbl_index  (cost=0.43..4.45 rows=1 width=23) (actual time=30.092..30.092 rows=0 loops=1)
   Index Cond: (a IS NULL)
 Planning time: 33.783 ms
 Execution time: 41.838 ms
(4 rows)

Time: 102.544 ms
test=# explain analyze select * from tbl_index where a is not null;
                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=0.00..115899.00 rows=10000000 width=23) (actual time=3.062..6309.908 rows=10000000 loops=1)
   Filter: (a IS NOT NULL)
 Planning time: 0.099 ms
 Execution time: 6877.566 ms
(4 rows)

Time: 6878.156 ms

以上比较可知where a is null索引生效，但是where a is not null导致索引生效。类似导致索引失效的还有NOT IN，NOT LIKE等，但是NOT EXISTS不会导致索引失效。下面的例子可以看到tbl_index表仍进行索引扫描，但是性能仍有限制，使用NOT IN虽然索引失效，但性能比NOT EXISTS要高。这个和我之前的认识有些出入，之前测试发现NOT EXISTS比NOT IN性能高，看来情况不同，性能也是不一定的。

test=# explain analyze select * from tbl_index where a not in (select a from tbl_test );
                                                       QUERY PLAN                                                        
-------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=14.50..140913.50 rows=5000000 width=23) (actual time=1.393..3717.312 rows=9999000 loops=1)
   Filter: (NOT (hashed SubPlan 1))
   Rows Removed by Filter: 1000
   SubPlan 1
     ->  Seq Scan on tbl_test  (cost=0.00..12.00 rows=1000 width=8) (actual time=0.038..0.236 rows=1000 loops=1)
 Planning time: 0.134 ms
 Execution time: 4147.857 ms
(7 rows)

Time: 4148.615 ms
test=# explain analyze select * from tbl_index where not exists (select null from tbl_test where tbl_test.a = tbl_index.a);
                                                                       QUERY PLAN                                                    
                    
-------------------------------------------------------------------------------------------------------------------------------------
--------------------
 Merge Anti Join  (cost=62.45..218187.26 rows=9999000 width=23) (actual time=1.698..16909.581 rows=9999000 loops=1)
   Merge Cond: (tbl_index.a = tbl_test.a)
   ->  Index Scan using idx_tbl_index_a on tbl_index  (cost=0.43..193110.43 rows=10000000 width=23) (actual time=0.035..14781.400 row
s=10000000 loops=1)
   ->  Sort  (cost=61.83..64.33 rows=1000 width=8) (actual time=0.390..0.659 rows=1000 loops=1)
         Sort Key: tbl_test.a
         Sort Method: quicksort  Memory: 71kB
         ->  Seq Scan on tbl_test  (cost=0.00..12.00 rows=1000 width=8) (actual time=0.038..0.194 rows=1000 loops=1)
 Planning time: 0.339 ms
 Execution time: 17530.472 ms
(9 rows)

Time: 17594.258 ms

 

4.模糊查询通配符在开头

test=# explain analyze select * from tbl_index where c like 'bit%';
                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=0.00..140899.00 rows=10000000 width=23) (actual time=0.099..1685.317 rows=10000000 loops=1)
   Filter: ((c)::text ~~ 'bit%'::text)
 Planning time: 55.373 ms
 Execution time: 2104.863 ms
(4 rows)

Time: 2164.464 ms

test=# explain analyze select * from tbl_index where c like '%me';
                                                        QUERY PLAN                                                         
---------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=0.00..140899.00 rows=10000000 width=23) (actual time=20.172..5507.741 rows=10000000 loops=1)
   Filter: ((c)::text ~~ '%me'::text)
 Planning time: 65.603 ms
 Execution time: 6007.367 ms
(4 rows)

 

5.索引字段在表中占比较高

test=# insert into tbl_index values (10000001,'2015-05-23 00:00:00','haha');
INSERT 0 1
Time: 88.226 ms
test=# explain analyze select * from tbl_index where c = 'bit me';
                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Seq Scan on tbl_index  (cost=0.00..140899.00 rows=10000000 width=23) (actual time=0.051..6758.236 rows=10000000 loops=1)
   Filter: ((c)::text = 'bit me'::text)
   Rows Removed by Filter: 1
 Planning time: 0.128 ms
 Execution time: 7237.900 ms
(5 rows)

Time: 7238.685 ms
test=# explain analyze select * from tbl_index where c = 'haha';
                                                         QUERY PLAN                                                         
----------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_c on tbl_index  (cost=0.43..4.45 rows=1 width=23) (actual time=0.063..0.065 rows=1 loops=1)
   Index Cond: ((c)::text = 'haha'::text)
 Planning time: 0.219 ms
 Execution time: 2.869 ms
(4 rows)

Time: 4.942 ms

 

test=# drop index idx_tbl_index_a;
DROP INDEX
Time: 134.873 ms
test=# drop index idx_tbl_index_c;
DROP INDEX
Time: 173.572 ms

 

6.多字段btree索引查询条件不包含第一列

test=# explain analyze select * from tbl_index where a = 10000001 and c = 'haha';
                                                           QUERY PLAN                                                           
--------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_a_c on tbl_index  (cost=0.43..6.20 rows=1 width=23) (actual time=23.254..23.257 rows=1 loops=1)
   Index Cond: ((a = 10000001) AND ((c)::text = 'haha'::text))
 Planning time: 36.050 ms
 Execution time: 35.710 ms
(4 rows)

Time: 78.816 ms
test=# explain analyze select * from tbl_index where  c = 'haha';
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..68982.44 rows=1 width=23) (actual time=7869.579..7890.974 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on tbl_index  (cost=0.00..67982.34 rows=0 width=23) (actual time=7468.480..7468.480 rows=0 loops=3)
         Filter: ((c)::text = 'haha'::text)
         Rows Removed by Filter: 3333333
 Planning time: 0.130 ms
 Execution time: 7891.137 ms
(8 rows)

Time: 7891.937 ms
test=# explain analyze select * from tbl_index where a = 10000001;
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_a_c on tbl_index  (cost=0.43..8.45 rows=1 width=23) (actual time=0.154..0.156 rows=1 loops=1)
   Index Cond: (a = 10000001)
 Planning time: 0.257 ms
 Execution time: 0.206 ms
(4 rows)

Time: 1.119 ms

 

7.多字段索引查询条件使用OR

test=# explain analyze select * from tbl_index where a = 10000001 or c = 'haha';
                                                         QUERY PLAN                                                          
-----------------------------------------------------------------------------------------------------------------------------
 Gather  (cost=1000.00..79399.11 rows=1 width=23) (actual time=7321.821..7323.593 rows=1 loops=1)
   Workers Planned: 2
   Workers Launched: 2
   ->  Parallel Seq Scan on tbl_index  (cost=0.00..78399.01 rows=0 width=23) (actual time=7307.413..7307.413 rows=0 loops=3)
         Filter: ((a = 10000001) OR ((c)::text = 'haha'::text))
         Rows Removed by Filter: 3333333
 Planning time: 0.163 ms
 Execution time: 7324.821 ms
(8 rows)

Time: 7325.532 ms
test=# explain analyze select * from tbl_index where a = 10000001 and c = 'haha';
                                                          QUERY PLAN                                                          
------------------------------------------------------------------------------------------------------------------------------
 Index Scan using idx_tbl_index_a_c on tbl_index  (cost=0.43..6.20 rows=1 width=23) (actual time=0.040..0.041 rows=1 loops=1)
   Index Cond: ((a = 10000001) AND ((c)::text = 'haha'::text))
 Planning time: 0.165 ms
 Execution time: 0.093 ms
(4 rows)

Time: 32.904 ms

 

转载于:https://www.cnblogs.com/alianbog/p/5648455.html

PostgreSQL查看索引是否失效
tttzzzqqq2018的博客
08-08 1645
PostgreSQL查看索引是否失效
PostgreSQL 如何应对因数据分布不均导致的部分索引失效？
发现生活，分享智慧，一起成长！
07-18 884
在数据库管理中，因数据分布不均导致的部分索引失效是一个常见的问题，但通过采取合适的解决方案，我们可以有效地提高数据库的性能。优化数据分布、创建合适的索引和定期维护索引是解决这个问题的关键。就像在生活中我们需要不断地调整和优化自己的生活方式一样，在数据库管理中，我们也需要不断地优化和改进我们的数据库设计和管理策略，以适应不断变化的业务需求。希望本文能够对大家在解决 PostgreSQL 中因数据分布不均导致的部分索引失效问题时提供一些帮助。记住，解决问题的关键在于深入理解问题的本质，并采取针对性的解决方案。
PostgreSQL 一则索引失效案例引发的思考
Focus on PostgreSQL
12-03 4345
前段时间碰到个奇怪的索引失效的问题，实际情况类似下面这样： bill=# begin; BEGIN bill=*# create index idx_t1 on t1(id); CREATE INDEX bill=*# explain select * from t1 where id = 1; QUERY PLAN ---------------------------------------------------- Seq Scan on t1 (cost
PostgreSQL 不能索引的10个原因
snowyar的专栏
07-26 5947
但是需要注意的是，为了个别的SQL，去盲目改变这些参数的值，往往是得不偿失的，操作的时候需要严谨并且仔细考虑，否则，这些类型的参数的改变，对于数据库的性能影响可能是巨大的。如果索引列中有大量重复的数据，或者一个字段全是一个值，这个时候，索引可能并不能发挥它的作用，起到加快检索的作用，因为这个索引并不能显著地减少需要扫描的行数，所以计算的代价可能远远大于走别的执行计划的代价。关闭对应的优化器选项，可以看到CBO受到设置的参数的影响，选择了seq scan的执行计划，而没有用到字段上的索引。
B-tree不是万能药：PostgreSQL索引失效的7种高频场景与破解方案
06-22 875
PostgreSQL中B-tree索引失效的常见场景与解决方案 摘要：本文分析了PostgreSQL中导致B-tree索引失效的7种典型场景：1）隐式类型转换导致索引无法命中；2）函数包裹索引列破坏有序性；3）前导通配符查询使B-tree失去优势；4）NULL值未被标准索引存储；5）联合索引违反最左前缀原则；6）非等值查询范围过大时优化器放弃索引；7）数据分布不均引发优化器误判。针对每种场景，文章提供了具体案例和解决方案，包括显式类型转换、创建函数索引、使用pg_trgm扩展、建立条件索引、优化联合索引顺序
PostgreSQL 如何应对因查询条件变化频繁导致的索引失效？
2401_86074221的博客
07-17 1309
在数据库管理中，因查询条件变化频繁导致的索引失效是一个常见的问题。通过合理设计索引、使用覆盖索引、定期重建索引、使用分区表和优化查询语句等措施，我们可以有效地解决这个问题，提高数据库的性能。就像一场战斗，我们需要根据敌人的情况，灵活运用各种战术，才能取得胜利。在数据库管理中，我们也需要根据实际情况，选择合适的解决方案，才能保证数据库的高效运行。🎉相关推荐🍅关注博主🎗️带你畅游技术世界，不错过每一次成长机会！📚领书：PostgreSQL 入门到精通.pdf📙PostgreSQL 中文手册。
PostgreSql 索引失效
azhegps的博客
07-27 9138
什么是索引失效？如果where过滤条件设置不合理，即使索引存在，且where过滤条件中包含索引列，也会导致全表扫描，索引不起作用。什么条件下会导致索引失效呢？ 1、任何计算、函数、类型转换 2、!= 3、NOT，相当于使用函数 4、模糊查询通配符在开头 5、索引字段在表中占比较高 6、多字段btree索引查询条件不包含第一列 7、多字段索引查询条件使用OR（有时也会走索引扫描，但查询效率不高） ...
postgresql 索引状态_postgresql----索引失效
weixin_39607423的博客
12-18 3112
什么是索引失效？如果where过滤条件设置不合理，即使索引存在，且where过滤条件中包含索引列，也会导致全表扫描，索引不起作用。什么条件下会导致索引失效呢？1.任何计算、函数、类型转换2.!=3.NOT，相当于使用函数4.模糊查询通配符在开头5.索引字段在表中占比较高6.多字段btree索引查询条件不包含第一列7.多字段索引查询条件使用OR(有时也会走索引扫描，但查询效率不高)测试表test=#...
PostgreSQL 如何应对因数据分布不均导致的索引失效？
发现生活，分享智慧，一起成长！
07-12 1062
但是，如果在这个数据集中，只有少数几种产品被频繁销售，而大部分产品很少被销售，那么当我们根据产品 ID 进行查询时，索引可能就无法有效地筛选出数据。如果没有索引，数据库就需要对整个数据表进行扫描，这就如同在没有目录的情况下，要在一本厚厚的书中逐页查找特定的内容，其效率之低可想而知。比如说，我们可以将销售数据表按照年度进行分区，这样在查询特定年度的销售数据时，数据库只需要在对应的分区中进行操作，减少了数据量，也就提高了索引的效果。比如，在创建索引时，要避免过度创建，因为过多的索引会增加数据插入和更新的开销。
PostgreSql like 不走索引
脑子进水养啥鱼？的博客
01-20 3098
测试发现 like 使用后缀通配符（%）时不走索引。
为什么pgsql(内关联查询或者with字句时)会导致索引失效
weixin_48811255的博客
01-30 1426
pgsql索引失效
Mysql、Oracle、PostgreSql数据库索引失效场景详细讲解
xgb2018的博客
10-23 2166
Mysql、Oracle、PostgreSql数据库索引失效场景详细讲解前言 前言 Mysql、Oracle、PostgreSql数据库索引失效场景详细讲解。废话不多说直接贴： 1、任何计算、函数、类型转换 2、!=、<> 3、IS NULL或者IS NOT NULL。类似导致索引失效的还有NOT IN，NOT LIKE等，但是NOT EXISTS不会导致索引失效。 4、模糊查询通配符在开头 5、索引字段在表中占比较高 6、多字段btree索引查询条件不包含第一列 7、在WHERE中使用OR时，
数据库索引失效
Ssl5829662884的博客
04-15 675
索引并不是时时都会生效的，比如以下几种情况，将导致索引失效： 1.如果条件中有多个字段使用or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因)。同一字段使用or时，索引会生效 　　注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引 　　2.对于多列索引，不是使用的第一部分，则不会使用索引，建立了联合索引，不是使用联合索引中的第一个索引搜索时，...
PG索引失败排查记录
sunquan291的专栏
08-25 2964
首先系统使用的是postgre数据库，突然业务逻辑中存在性能问题，最终慢查询定位后，跟踪到有一个过滤查询，耗时严重。如果只有前模糊查询需求(字符串 like ‘xx%’)，使用collate "C"的b-tree索引；当collate不为"C"时，可以使用类型对应的pattern ops(例如text_pattern_ops)建立b-tree索引。
PostgreSql查看索引
snn1410的专栏
07-17 8868
PostgreSQL .   select * from pg_indexes where tablename='log';   或select * from pg_statio_all_indexes where relname='log';   详情请参考http://haohetao.iteye.com/blog/800749 里面有PDO数据库笔记和php相关知识
哪些情况下索引会失效？
weixin_34127717的博客
10-22 619
索引并不是时时都会生效的，比如以下几种情况，将导致索引失效： 如果条件中有or，即使其中有条件带索引也不会使用(这也是为什么尽量少用or的原因) 　　 　　注意：要想使用or，又想让索引生效，只能将or条件中的每个列都加上索引 　　2.对于多列索引，不是使用的第一部分，则不会使用索引 　　3.like查询是以%开头 　　4.如果列类型是字符串，那一定要在条件中将数据使用引号...
Postgresql索引
qq_47255712的博客
06-01 643
Postgresql索引 1.查看索引 select * from pg_indexes where tablename='table_name'; select * from pg_statio_all_indexes where relname='table_name'; 注意：tablename和relname后面的 ‘’ 内的是 表名称 2.创建索引 create index index_name on table_name(id,name); 注意：index_name 是
【PG里常见的字段有索引但没有使用索引的原因】
小怪兽的博客
05-05 2829
对于一个系统而言，稳定性、性能、安全是很重要的几点。运维的一些工作也是围绕着这些去做。对于某些时候，业务层可能会向数据库层提出种种质疑：为什么数据库这么慢？为什么数据库挂了？为什么我这么用，SQL走不了索引？诸如此类。其实对于了解数据库和运维的大家都知道，这些使用关系型数据库的应用系统，SQL语句的好坏会直接影响系统的性能，很多系统性能很差最后发现都是因为SQL写得很烂的缘故。
postgresql索引失效条件
最新发布
08-05
### PostgreSQL 索引失效的条件 在 PostgreSQL 中，索引的使用效率受到查询条件、数据分布以及索引结构的影响。以下是一些常见的导致索引失效的条件： #### 1. **对索引列进行计算或函数操作** 当在查询条件中对索引列进行计算、使用函数或类型转换时，PostgreSQL 通常无法直接使用索引。例如： ```sql SELECT * FROM users WHERE EXTRACT(YEAR FROM birth_date) = 1990; ``` 此查询无法使用 `birth_date` 上的普通 B-tree 索引，因为查询条件中使用了函数 `EXTRACT` [^3]。 #### 2. **使用 `!=` 或 `<>` 运算符** 当查询条件中使用了 `!=` 或 `<>` 运算符时，索引通常不会被使用，因为这些操作符无法有效利用 B-tree 索引的有序性。 ```sql SELECT * FROM users WHERE status != 'active'; ``` 该查询通常不会使用 `status` 列上的索引 。 #### 3. **使用 `NOT` 条件** `NOT` 条件本质上等同于使用了函数，因此可能导致索引失效。例如： ```sql SELECT * FROM users WHERE NOT (status = 'active'); ``` 该查询通常不会使用 `status` 列上的索引 。 #### 4. **模糊查询以通配符开头** 当使用 `LIKE` 或 `ILIKE` 并以通配符（如 `%`）开头时，索引通常无法被使用。 ```sql SELECT * FROM users WHERE name LIKE '%john'; ``` 该查询无法使用 `name` 列上的普通 B-tree 索引 [^3]。 #### 5. **索引列在表中占比过高** 当某个索引列的值在整个表中占比过高时（例如超过 5%），PostgreSQL 查询优化器可能会选择全表扫描而不是使用索引，因为索引扫描的代价可能更高。 ```sql SELECT * FROM orders WHERE status = 'pending'; ``` 如果 `status = 'pending'` 的记录占比过高，查询优化器可能不会使用该列上的索引 [^1]。 #### 6. **多字段 B-tree 索引未包含第一列** 在使用多字段 B-tree 索引时，如果查询条件中没有包含索引的第一列，索引可能不会被使用。 ```sql CREATE INDEX idx_orders_user_status ON orders(user_id, status); SELECT * FROM orders WHERE status = 'shipped'; ``` 该查询不会使用 `idx_orders_user_status` 索引，因为查询条件中没有包含 `user_id` [^3]。 #### 7. **使用 `OR` 条件** 当查询条件中使用了 `OR`，并且 `OR` 两侧的列没有全部被索引覆盖时，索引可能不会被使用，或者即使使用，效率也不高。 ```sql SELECT * FROM users WHERE name = 'Alice' OR email = 'alice@example.com'; ``` 如果 `name` 和 `email` 上分别有索引，但查询优化器可能无法高效合并使用多个索引 [^3]。 #### 8. **数据分布不均** 当某个字段中某些值出现频率过高时（例如性别字段中“男”占绝大多数），在查询其他值时索引可能失效。例如： ```sql SELECT * FROM users WHERE gender = 'female'; ``` 如果 `gender = 'female'` 的记录占比很小，但索引扫描的效率仍然可能不如顺序扫描 [^1]。 #### 9. **查询条件频繁变化** 当查询条件频繁变化时，PostgreSQL 的查询优化器可能无法稳定地选择最优的索引路径，导致某些查询无法有效利用索引 [^2]。 --- ### 相关问题 1. PostgreSQL 中如何优化模糊查询以提升索引使用效率？ 2. 如何在 PostgreSQL 中创建合适的多字段复合索引？ 3. PostgreSQL 查询优化器是如何决定是否使用索引的？ 4. 在 PostgreSQL 中如何处理数据分布不均导致的索引失效问题？ 5. PostgreSQL 中如何监控索引的使用情况？
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值