PostgreSQL根据数据量、索引、统计信息和查询条件选择SeqScan或IndexScan；2. SeqScan适用于小表、无法用索引、访问大部分数据或统计信息过期；3. IndexScan适合高选择性查询且存在合适索引的情况。
PostgreSQL在执行查询时，会根据表的数据量、索引情况、统计信息以及查询条件来决定使用哪种扫描方式。最常见的两种是顺序扫描（SeqScan）和索引扫描（IndexScan）。选择合适的扫描方式对查询性能至关重要。
顺序扫描（SeqScan）适用场景
顺序扫描是指数据库从头到尾读取整张表的每一行数据，适用于以下情况：
- 表数据量小：当表中行数较少时，全表扫描开销不大，优化器更倾向于选择SeqScan。
- 查询条件无法利用索引：例如WHERE条件中的字段没有建立索引，或使用了不支持索引操作的表达式（如函数封装、模糊匹配前缀为%等）。
- 需要访问大部分数据：如果查询要返回超过10%-20%的行，走索引反而效率更低，因为每次通过索引定位都需要额外的随机I/O。
- 统计信息缺失或过期：若ANALYZE未及时更新统计信息，可能导致优化器误判选择性，错误地使用SeqScan。
索引扫描（IndexScan）适用场景
索引扫描通过B-tree、Hash、GiST等索引结构快速定位符合条件的数据行，适合：
- 高选择性查询：比如通过主键或唯一索引查找单条记录，或者WHERE过滤后只返回少量行。
- 有合适的索引存在：查询字段上有有效索引，并且查询操作符支持索引检索（如=, >,
- 覆盖索引部分查询需求：即使不能完全避免回表，也能显著减少需要读取的数据页数量。
- 排序与范围查询优化：索引本身有序，可用于避免额外排序（ORDER BY），或高效处理范围查询。
影响扫描方式选择的关键因素
PostgreSQL的查询规划器基于成本模型进行决策，主要参考以下几个方面：
- 表的统计信息：通过ANALYZE命令收集的行数、数据分布、空值比例等信息直接影响成本估算。
- 索引的选择度（Cardinality）：高基数字段（如用户ID）比低基数字段（如性别）更适合建索引。
- random_page_cost与seq_page_cost参数：这两个配置控制随机I/O和顺序I/O的相对代价，默认值分别为4.0和1.0。在SSD环境下可调低random_page_cost以鼓励更多IndexScan。
- enable_seqscan、enable_indexscan等GUC参数：可用于强制关闭某种扫描方式（仅用于调试，生产环境慎用）。
如何查看和干预扫描方式
可以通过EXPLAIN命令观察实际使用的扫描方式：
EXPLAIN SELECT * FROM users WHERE id = 100;
输出中出现“Seq Scan on users”表示全表扫描，“Index Scan using users_pkey on users”则表示使用了索引。
若发现应走索引却走了全表扫描，可尝试：
- 运行ANALYZE users;更新统计信息。
- 检查WHERE条件是否破坏了索引可用性（如
WHERE UPPER(name) = 'ABC'需对应函数索引）。 - 确认索引已创建且状态正常：\d users 查看索引定义。
- 调整work_mem或effective_cache_size等参数改善执行计划评估准确性。
基本上就这些。PostgreSQL的扫描方式选择是一个权衡过程，理解其背后的机制有助于写出高效的SQL并合理设计索引。
