嘿，这个问题问得挺接地气的，咱们结合你的实际场景一步步拆解分析下～

首先得抓住你的场景核心：归档的书只有10条，99.99%以上都是未归档的，而且所有查询都带着is_archived = false这个过滤条件。先说说你的初始思路，再聊聊不同索引方案的优劣。

先看你当前用单独索引的情况 #

你觉得单独用creator_id索引，PostgreSQL先取出10000条creator_id=1的行，再过滤出10条未归档的——这个逻辑其实没问题，而且实际性能大概率不会差：

• 因为归档数据总共才10条，分到单个creator_id下的可能寥寥无几甚至没有，所以PostgreSQL在遍历creator_id索引的时候，几乎扫到的前几条就是未归档的，很快就能凑够LIMIT 10的量，根本不用真的扫完10000条。
• 唯一的极端情况是：某个creator_id下恰好集中了几条归档数据，而且这些归档行在索引排序里排在前面，这时候PostgreSQL可能要多扫几条才能找到10条未归档的，但这种概率极低，几乎可以忽略。

再聊聊复合索引的可行性 #

你提到的creator_id+is_archived=false其实不用这么写，直接建(creator_id, is_archived)的复合索引就行。这种索引的优势是能直接定位到creator_id=1 AND is_archived=false的行，不用额外过滤，但也有小缺点：

• 复合索引的体积比单独的creator_id索引大，因为多存了一个is_archived字段，每次插入、更新book表时，维护这个索引的成本会略高一点。
• 如果你当前单独索引的查询已经快到毫秒级，换复合索引带来的性能提升几乎感知不到，完全没必要折腾。

更适合你场景的优化方案：部分索引 #

其实PostgreSQL的**部分索引（Partial Index）**才是为这种“大部分数据符合某条件”的场景量身定做的，比如针对未归档数据单独建索引：

-- 针对creator_id的部分索引
CREATE INDEX idx_book_creator_active ON book (creator_id) WHERE is_archived = false;
-- 针对created_at的部分索引
CREATE INDEX idx_book_created_at_active ON book (created_at) WHERE is_archived = false;

这个方案的好处很明显：

• 索引体积小：只包含未归档的行，比复合索引少存了is_archived字段，维护成本比复合索引还低。
• 查询效率高：PostgreSQL会自动识别到你的查询带了is_archived=false，直接走这个部分索引，一步到位找到目标行，不用额外过滤。

给你的最终建议 #

1. 如果当前单独索引的性能已经满足需求，完全不用改：毕竟归档数据极少，现有索引的查询速度已经足够，折腾索引反而可能带来额外的维护成本。
2. 如果想进一步优化，优先选部分索引：比复合索引更轻量，性价比更高。
3. 实际跑一遍EXPLAIN ANALYZE验证下：比如执行EXPLAIN ANALYZE SELECT * FROM book WHERE creator_id = 1 AND is_archived = false LIMIT 10，看看PostgreSQL实际的执行计划，要是已经是毫秒级的执行时间，真的没必要动索引。

最后补个小细节：你担心的“取10000行再顺序扫描”其实是想多了，PostgreSQL在遍历索引的时候，是扫一条就检查一条is_archived，符合条件就返回，直到凑够10条就停止，不会真的把10000条都取出来再过滤，实际性能比你预想的还要好～