带LIMIT的子查询比无LIMIT更快的PostGIS查询性能问题排查

一、table2子查询加LIMIT前后的性能差异原因 #

• 优化器执行计划选择失误
  没加LIMIT时，table2的GIST索引让优化器错误选择了基于索引的嵌套循环连接——等于用table2的每一行去驱动700万行的table1做空间检索，反复触发10次大表空间查询，耗时直接拉满。
• LIMIT 10直接修正了执行策略
  明确的LIMIT值让优化器放弃低效的索引使用，直接全量扫描table2（10行的小表全扫比走索引快得多），再用这10行批量关联table1，开销骤降。
• 移除table2索引解决问题的逻辑
  没有GIST索引后，优化器只能选择table2全表扫描，小表全扫几乎无开销，自然不会触发之前的低效执行计划。

二、table1子查询加LIMIT与不加LIMIT的差异原因 #

• TimescaleDB超表的分片特性干扰了执行计划
  table1作为超表被拆分为多个chunk分片，不加LIMIT时，优化器会尝试对所有chunk执行全局空间关联/聚合，跨chunk的数据扫描、合并开销极大，甚至触发低效连接策略，内存和IO直接过载，导致查询无法及时完成。
• 超总行数的LIMIT给了优化器“灵活执行”的信号
  虽然LIMIT值超过总行数，但等于告诉优化器“不用死磕全量数据”，它会改为按chunk顺序扫描，获取足够数据后就停止，还能触发流式执行减少内存占用，自然能顺利跑完。
• 移除table1索引+ANALYZE无效的原因
  超表的统计信息需要针对每个chunk单独更新，全局ANALYZE无法覆盖所有chunk的准确统计，优化器依然会选错执行计划；另外，移除索引后全量扫描所有chunk本身开销就极大，没LIMIT的情况下优化器还是要硬扫完所有数据，自然无法快速结束。

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