设计PostgreSQL复合索引需遵循最左前缀原则，即查询必须从索引最左列开始连续使用列，如索引(A, B, C)支持WHERE A=1或A=1 AND B=2，但不支持WHERE B=2或A=1 AND C=3；列顺序影响效率，应将高选择性或等值查询列放前面，例如user_id = 100 AND create_time > '2024-01-01'宜建索引(user_id, create_time)；优先构建覆盖索引以减少回表，如SELECT user_id, status FROM orders WHERE user_id = 100 AND status = 'paid'可使用(user_id, status)索引避免访问主表；合理利用INCLUDE子句存储非键列；避免冗余索引，已有(A, B)时通常无需单独建(A)，但(B)或(B, A)仍需根据查询需求保留；定期通过EXPLAIN ANALYZE分析执行计划，删除未使用或低效索引，结合实际查询模式和数据分布优化索引策略。
设计PostgreSQL联合索引（也称复合索引）时，关键在于理解查询模式和索引的最左前缀原则。一个设计良好的复合索引可以显著提升查询性能，而错误的设计可能导致索引无法使用或效果不佳。
1. 遵循最左前缀匹配规则
PostgreSQL的复合索引基于B-tree结构，查询条件必须从索引列的最左边开始，并连续使用索引中的列，才能有效利用索引。
- 如果索引是 (A, B, C)，那么以下查询可用该索引：
- WHERE A = 1
- WHERE A = 1 AND B = 2
- WHERE A = 1 AND B = 2 AND C = 3
- 但以下情况可能无法使用或只能部分使用索引：
- WHERE B = 2（跳过A，无法使用）
- WHERE A = 1 AND C = 3（缺少B，C无法生效）
2. 列顺序决定索引效率
在创建 (A, B) 这样的复合索引时，A 是主导列，B 是次导列。应将选择性高、过滤性强的列放在前面。
- 高选择性列优先：比如 status 只有两个值，而 created_at 范围广泛，created_at 更适合放前面。
- 等值查询列在前：WHERE 中使用 = 的列应优先于范围查询（如 >,
- 例如：WHERE user_id = 100 AND create_time > '2024-01-01'，建议索引为 (user_id, create_time)，因为 user_id 是等值匹配，能快速缩小范围。
3. 覆盖索引减少回表
如果索引包含了查询所需的所有字段，称为“覆盖索引”，可避免访问主表数据，提升性能。
- 例如：SELECT user_id, status FROM orders WHERE user_id = 100 AND status = 'paid';
- 创建索引 (user_id, status) 可让查询完全在索引中完成，无需回表。
- 注意：INCLUDE 子句可用于非键列（PostgreSQL 11+），如 CREATE INDEX idx ON orders (user_id) INCLUDE (status, amount);
4. 避免冗余和过度索引
过多索引会增加写入开销（INSERT/UPDATE/DELETE）并占用存储。
- 已有 (A, B) 索引时，(A) 单列索引通常是冗余的（除非单独用于其他查询）。
- 但 (B) 或 (B, A) 不会被 (A, B) 覆盖，不能省略。
- 定期分析查询日志和执行计划（EXPLAIN ANALYZE），删除未使用或低效的索引。
基本上就这些。合理设计复合索引需要结合实际查询语句、数据分布和业务场景，不要盲目添加索引，而是通过执行计划验证其有效性。不复杂但容易忽略。
