索引未生效主因是查询条件不匹配、数据选择性差、隐式转换或配置限制。1. 查询条件中索引列被函数处理、复合索引前导列缺失、操作符不支持将导致无法使用索引；2. 数据重复度高、统计信息过期或表小使优化器倾向顺序扫描；3. 类型不匹配如字符串与数字比较、时区混用或函数操作破坏索引匹配；4. 部分索引条件不符、参数关闭索引扫描、索引无效或未VACUUM影响可见性。应通过EXPLAIN ANALYZE查执行计划，核对pg_stat_user_indexes扫描次数，定期ANALYZE和VACUUM确保统计准确。
PostgreSQL中索引扫描未生效，往往不是因为索引不存在，而是查询条件、数据分布或执行计划选择导致优化器放弃了索引。理解索引为何“失效”，关键在于搞清楚优化器的决策逻辑和常见陷阱。
1. 查询条件不匹配索引结构
即使表上有索引，若查询的WHERE条件无法利用该索引的列顺序或操作符，索引就不会被使用。
- 索引列在表达式中被修改，如 WHERE UPPER(name) = 'JOHN'，即使 name 有索引，UPPER函数会阻止直接使用该索引，除非创建函数索引。
- 查询使用了不支持索引的操作符，例如某些自定义类型或非 B-tree 支持的操作。
- 复合索引的前导列未出现在查询中，如索引为 (a, b, c)，但查询只用了 WHERE b = 1，通常不会走索引（除非是覆盖索引且启用了位图扫描）。
2. 数据选择性差或统计信息不准
当查询返回大量行时，顺序扫描可能比索引扫描更快。优化器基于成本估算决定是否使用索引。
- 如果某列的值高度重复（如性别字段只有“男”“女”），查询该列时优化器可能判断全表扫描更高效。
- 表的统计信息过期，ANALYZE 未及时运行，导致行数、数据分布估计错误，影响执行计划生成。
- 小表通常直接顺序扫描，因为读取整个表的成本低于多次随机IO访问索引+堆表。
3. 隐式类型转换或函数干扰
看似简单的查询，可能因类型不匹配导致索引无法命中。
- 字符串与数字比较，如 WHERE status = 1，而 status 是文本类型，会触发隐式转换，破坏索引使用。
- 时间字段查询中混用时区，如 timestamp with time zone 和 without time zone 混用，可能导致表达式不可索引。
- 在索引列上使用 to_char、date_trunc 等函数，必须创建对应的函数索引才能生效。
4. 索引本身问题或配置限制
索引存在不代表可用，还需检查其状态和数据库配置。
- 索引被标记为 INVALID（如创建中途失败），需重建。
- 部分索引（partial index）的 WHERE 条件不满足当前查询，自然不会被选中。
- 配置参数如 enable_indexscan、enable_bitmapscan 被关闭，强制禁用索引访问方式。
- 事务可见性问题，如大量更新后未 vacuum，导致索引条目指向过期数据，影响效率。
排查建议：使用 EXPLAIN ANALYZE 查看实际执行计划，确认是否走了索引；检查 pg_stat_user_indexes 中的 idx_scan 字段，若长期为0，说明该索引从未被使用；定期运行 ANALYZE，必要时手动 VACUUM。
基本上就这些。索引不生效不是玄学，而是优化器在特定条件下做出的“合理”选择。关键是让查询“适合”索引，而不是以为建了索引就万事大吉。
