PostgreSQL表继承场景下全表扫描而非索引扫描的原因排查

1. 统计信息偏差或过时 #

PostgreSQL的优化器完全依赖统计数据计算执行成本。如果addresses或其继承子表（warehouses/pudos/agencies）的统计信息过时、不准确，优化器会错误判断索引扫描的成本高于全表扫描。尤其是表继承架构下，子表的统计数据默认可能没被正确聚合到父表的统计中，导致优化器误判整体数据规模。

• 手动更新统计信息：ANALYZE VERBOSE addresses; 别忘了同时更新子表的统计，或者用ANALYZE VERBOSE warehouses, pudos, agencies;确保所有关联表的统计都是最新的。

2. 数据量与成本权衡 #

当查询需要返回addresses表大部分数据时，优化器会认为全表扫描更高效。因为索引扫描需要先读索引再回表取数据，多次随机IO的成本会超过直接扫描整张表的顺序IO成本。而添加LIMIT或过滤条件后，返回行数骤减，索引快速定位少量数据的优势就凸显出来了。

• 用EXPLAIN ANALYZE跑一下你的查询，对比优化器估算的返回行数和实际行数。如果估算偏差大，说明统计信息有问题；如果估算接近实际，那就是优化器基于成本做出的合理选择。

3. 表继承架构的特殊限制 #

PostgreSQL的表继承在处理多表关联时，优化器对继承表的索引逻辑存在特殊性：

• 父表的索引不会自动同步到新增的子表（仅创建索引时的现有子表会被包含），你得确认warehouses/pudos/agencies这些子表是否有针对id的有效索引；
• 多表左关联场景下，继承表的存在会让优化器的成本计算变得复杂，可能导致它放弃索引扫描，转而选择更“稳妥”的全表扫描。

4. 内存配置不足 #

你的实例是8GB内存，PostgreSQL的shared_buffers和work_mem配置直接影响优化器决策：

• shared_buffers如果设置太小，数据库无法缓存足够的索引或数据块，会增加IO成本，优化器可能因此放弃索引扫描；
• work_mem过小的话，关联操作（比如哈希关联）的成本会被高估，优化器可能倾向于全表扫描。
• 查看当前配置：SHOW shared_buffers; SHOW work_mem; 8GB内存的实例建议shared_buffers设为2GB左右，work_mem根据并发数调整到64MB-128MB（避免并发时内存溢出）。

5. 左关联的固有特性 #

左关联要求返回左表（addresses）的所有行，哪怕右表没有匹配数据。如果addresses表数据量很大，优化器会认为：直接扫描整张addresses表，再逐一关联子表的成本，比通过索引逐个查找addresses.id对应的子表数据更低。而添加过滤条件后，addresses的返回行数大幅减少，索引扫描的成本优势就体现出来了。

内容的提问来源于stack exchange，提问作者Gammel