Henrietta Dombrovskaya：当无法优化时如何优化！
内容提要
文章讨论PostgreSQL查询优化问题。面对16亿行大表，查询因日期范围条件而变慢，但构建索引耗时过长不可行。解决方案是创建映射表记录每个组合的最小起始日期，通过子查询限制范围，使查询从数秒降至百毫秒内。最终建议使用外部表避免数据冗余，保持性能。
延伸解读
索引并非万能：构建成本与查询性能的权衡
文章指出，在16亿行的大表上构建GIST索引可能耗时超过24小时，因此不可行。这提醒我们，索引虽然能加速查询，但构建和维护成本可能过高，尤其在超大数据集上。实际工作中，需要权衡索引带来的性能提升与构建时间、存储开销，有时需要寻找替代方案。
映射表与外部表的巧妙应用
通过创建映射表记录每个组合的最小起始日期，并利用子查询限制扫描范围，查询性能从数秒提升至百毫秒内。当客户不愿维护冗余数据时，进一步采用外部表（foreign table）实现跨数据库访问，既避免了数据重复，又保持了性能。这展示了在无法直接优化索引时，通过数据组织或外部数据源来优化查询的实用思路。
部分索引的应急价值
在无法全面构建索引的情况下，针对客户指定的高频查询条件构建部分索引（partial indexes），使这些查询无需修改即可提速至100毫秒以下。这提示我们，当全量索引不可行时，可以优先覆盖关键查询模式，以最小成本解决主要性能问题。
Q&A
PostgreSQL中面对16亿行的大表，构建索引耗时过长，有什么替代优化方案？
文章提出了一种替代方案：创建一个映射表（或外部表），记录每个组合（a, b, c）的最小起始日期（start_date）。查询时，通过子查询从映射表中获取该组合的最小起始日期，并将其作为额外的过滤条件，从而大幅减少需要扫描的数据量，使查询从数秒降至百毫秒内。
为什么在16亿行的大表上构建GIST索引不可行？
因为构建任何索引在16亿行上都需要很长时间，而GIST索引的构建时间可能超过24小时，因此不可行。
在优化查询时，为什么添加 start_date >= '2026-01-01' 这样的条件不够有效？
因为该条件可能无法覆盖所有需要的数据，用户需要捕获“一切”记录，即从该组合首次出现的日期开始的所有记录。如果最小起始日期远早于2026-01-01，则此条件会漏掉部分数据，且查询性能提升有限。
使用映射表优化查询时，如何获取每个组合的最小起始日期？
可以通过两种方式：一是将映射表作为普通表存储在数据库中，二是使用外部表（foreign table）引用其他数据库中的现有表，避免数据冗余。查询时通过子查询从映射表或外部表中获取对应组合的最小起始日期。
为什么最终推荐使用外部表而不是在本地维护映射表？
因为客户已经在另一个数据库中维护了包含最小起始日期的列表，他们不希望在同一数据上维护两份副本，以避免数据冗余。使用外部表可以直接引用现有数据，无需复制，同时保持性能。
优化后的查询为什么能显著提升性能？
优化后的查询通过子查询从映射表或外部表获取该组合的最小起始日期，并将其作为额外的过滤条件（start_date >= first_date），从而大幅减少需要扫描的行数，使查询时间从数秒降至百毫秒内。
