数据库多字段索引查询中AND运算符的工作原理

你之前对单条件下B-tree索引高效检索的理解是正确的。先直接说结论：你担心的「拿到owner结果集后全扫描再匹配status」只是数据库的备选方案之一，绝大多数情况下都会走更高效的优化，核心方案分两种：

1. 索引交集（Index Intersection） #

所有单列B-tree二级索引的叶子节点，都会存储「索引列值 + 对应行的主键/物理行ID」的有序映射。
对于你给出的查询：

SELECT * FROM posts WHERE owner="abc" AND status="public"

数据库会先并行（或顺序）通过两个索引分别拿到：

• owner索引下，所有owner="abc"对应的行ID列表，已经按行ID有序排列
• status索引下，所有status="public"对应的行ID列表，同样按行ID有序排列
  因为两个列表都是有序的，数据库可以用双指针归并的方式快速求两个集合的交集，整个过程时间复杂度只有O(N+M)（N、M分别是两个条件对应的行数量），不需要对单个结果集做逐行全扫。
  拿到同时符合两个条件的行ID后，再批量回表查询这些行的所有字段，就是最终结果。

2. 单索引扫描 + 后置过滤 #

数据库的优化器会提前基于表的统计信息（比如字段的基数、符合条件的行占比）计算所有可选方案的成本，选成本最低的执行路径。
如果其中一个条件的过滤性远好于另一个，比如owner="abc"对应的行只有10条，而status="public"对应的行有100万条，那走索引交集需要处理两个超大列表，成本反而更高。这种情况下优化器会直接走owner索引拿到10个行ID，回表的时候逐行判断status是否等于public，10次判断的成本几乎可以忽略，效率远高于求交集。

优化器的兜底决策 #

如果两个条件的选择性都极低（比如owner="abc"占全表50%的行，status="public"也占50%），那求交集的成本甚至高于全表扫描，这种情况下数据库会直接走全表扫描，逐行匹配两个条件。

额外优化建议 #

如果这类查询是高频查询，更优的方案是建(owner, status)的联合索引，这种情况下数据库可以直接通过一次索引扫描拿到同时符合两个条件的行ID，不需要求交集，效率会比两个单列索引更高。

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