报表查询的救命稻草：复合索引与最左前缀

场景建了 (user_id, created_at) 复合索引，只按 created_at 查却不走索引--为什么？

复合索引的排序规则：先按第一列排，第一列相同时再按第二列排。像电话簿「先姓后名」：知道姓能二分定位；只知道名（=只用第二列），整本电话簿还是得翻一遍。所以 (user_id, created_at) 支持「只 user_id」「user_id + created_at」，不支持只 created_at。

create index on orders (user_id, created_at);

-- 命中
explain select * from orders where user_id = '...';
explain select * from orders where user_id = '...' and created_at >= current_date - 30;
-- 不命中（最左前缀断了）
explain select * from orders where created_at >= current_date - 30;

易错「(a, b) 能不能服务 where b」是索引面试的必考送分/送命题，先讲清排序原理再给结论。

场景同样两列，先建 (user_id, created_at) 还是 (created_at, user_id)？

① 等值在前、范围在后：范围条件命中后，索引里它后面的列就没法继续精确定位了。(user_id = ? and created_at > ?) 用 (user_id, created_at)：user_id 等值定位后，created_at 在索引里还是有序的，范围顺藤摸瓜。反过来范围在前，user_id 就乱序了。② 多个等值列之间，高选择性（区分度大的）优先。

-- 报表标配：某用户的某时间段
create index on orders (user_id, created_at);   -- 对
-- create index on orders (created_at, user_id); -- created_at 的范围会挡住 user_id 的等值定位

易错范围列一旦「挡路」，它后面的列在索引里就只剩过滤作用（Filter），不再参与定位（Index Cond）--看 EXPLAIN 的这两个字段能立刻诊断。

场景「这列建索引值不值」要拿数字说话。

选择性 = 不同值数量 / 总行数，越接近 1 区分度越大、索引越值。status 列选择性 ≈ 0.000003（100 万行 3 个值），索引意义小；email 接近 1，必建。PG 里看 pg_stats.n_distinct（正数 = 绝对值、负数 = 占总行数的比例）。

select attname, n_distinct, null_frac
from pg_stats
where tablename = 'orders';
-- user_id 的 n_distinct ≈ -0.01（约 1% 行数即 1 万个不同用户）
-- status 的 n_distinct = 3

易错「低选择性列单独建索引」= 白占空间：优化器预判命中太多行，照样全表扫。

场景列表页只要 id、金额、时间--这些列全在索引里的话，连堆都不用回。

查询涉及的列全部包含在索引里时，扫描器理论上可以只读索引--Index Only Scan，省掉回表的随机 IO。include (列) 把额外列塞进索引叶子（不参与排序），是官方支持的「为 IOS 补货」写法。

create index on orders (user_id, created_at) include (total_amount);

explain (analyze, buffers)
select user_id, created_at, total_amount
from orders
where user_id = '...' and created_at >= current_date - 30;
-- 计划出现 Index Only Scan，Heap Fetches = 0

易错include 会加大索引、拖慢写入--只为偶尔一条查询加它不值；高频接口查询才值得。

场景明明列都在索引里，计划却时不时回堆几万次（Heap Fetches > 0）--为什么？

索引里没有行的可见性信息（MVCC 的 xmin/xmax 在堆上），IOS 必须确认「这行对当前事务可见」。靠 visibility map：每个堆页一个「全可见」位，VM 置位的页才敢直接用索引。VM 由 vacuum 维护--表刚大量更新过，VM 退化，IOS 又偷偷回表了。

explain (analyze, buffers) select user_id from orders where user_id = '...';
-- Heap Fetches: 12345   <- 回堆了，VM 不干净
vacuum orders;
explain (analyze, buffers) select user_id from orders where user_id = '...';
-- Heap Fetches: 0       <- VM 全可见，真·只读索引

易错「IOS 时快时慢」的老大难，先想 VM 和 vacuum；autovacuum 跟不上就调参（D41 讲）。