索引首先是一条访问路径
查询写了筛选条件，并不意味着数据库必须逐行读取整张表；索引提供另一条寻找候选记录的路径。但索引也不是免费的加速开关：它占空间，写入时可能需要维护，是否值得使用还取决于数据规模、分布与查询返回比例。本文讨论普通 B 树复合索引，而不是所有索引类型。
复合索引包含多个有顺序的键列。可以先用字典排序作类比：先按第一列排列，第一列相同再按第二列排列。类比用来理解哪些记录集中在连续区域，不代表数据库把完整表按照相同顺序物理存储。表的存储与索引的排序是两个概念。
原创数据：按课程找一段日期内的预约
设教学表 bookings 有 course、day、student_id 三列，日期用统一格式表示。六条记录为：BIO 的 10 月 1、3、8 日各一条；CHEM 的 10 月 2、3 日各一条；MATH 的 10 月 3 日一条。这里只用虚构编号和课程代码，不含真实学生信息。
建立 (course, day) 索引后，BIO 的三个键集中在一起，内部按日期排列。查询条件是 course='BIO' 且 day≥'2026-10-03' 且 day<'2026-10-09'，对应 BIO 区域中的 3 日和 8 日两条记录。半开日期区间也有利于明确上限，但字段若为时间戳，仍需说明时区和时间边界。
等值前缀与第一段范围怎样配合
第一列的等值条件先把范围缩到某门课程，第二列的日期范围再缩小其中一段。这解释了为什么 (course, day) 往往适合“指定课程加日期区间”的查询。不能只说两个字段都有索引，而要描述候选键落在哪个有序范围。
现在把索引改为 (day, course)。同一日期内的课程相邻，但 BIO 会分散在不同日期组中。日期范围可以先缩小扫描部分，课程条件继续检查候选键；它仍可能有用，只是访问方式与前一种不同。两种索引谁更好，要结合实际数据与查询组合验证，不能用六条示意数据宣布性能结论。
“缺少最左列就完全失效”说得太绝对
如果只查询 day='2026-10-03'，(course, day) 中各课程的这一天分散在不同位置。朴素理解下，无法直接把它当作一个紧凑的单一区间。但 PostgreSQL 官方文档明确说明，多列 B 树索引可以用于涉及任意部分索引列的条件；能用与能高效缩小扫描范围不是同一件事。
在 PostgreSQL 18 文档所述的跳跃扫描优化中，规划器可能利用前导列不同值不多等特点，对后续列条件进行多次索引搜索。因此“必须从第一列开始，否则永远不能用”的口诀不够准确。其他数据库和版本的优化能力可能不同，写报告时应同时说明产品、版本及观察到的计划。
第三列条件不一定继续缩短同一段扫描
考虑 (course, day, student_id) 索引，查询已经固定 course，并给 day 一个范围，再加 student_id=42。学生编号条件可以帮助排除候选项，但不能简单地认为它必然把所有 42 号记录压成一个连续小区间，因为在每个日期组中仍按学生编号排序。
对原创示意数据，假设 BIO 在 3 日有编号 10、42，8 日有编号 11、42。学生 42 的两条记录之间隔着其他日期和编号的键。先画排序后的键元组，就能理解为什么后续条件与第一段范围的作用不同。实际优化器也可能采用更复杂的导航策略，最终仍应以计划和测量为准。
用 EXPLAIN 验证，而不是只观察有没有索引名
在练习环境中，先记录原查询和数据量，再查看 EXPLAIN 输出，识别顺序扫描、索引扫描或位图访问等节点。观察哪些条件用于索引访问、哪些在后续过滤，同时比较估计返回行数。一个计划出现索引名，并不自动证明总工作量更少。
需要实际测量时，可在合适的测试环境使用 EXPLAIN ANALYZE；它会真正执行语句，所以不能把它当成任何写语句都安全的只读解释器。对只读练习查询，也要考虑缓存、重复运行与并发负载。估计行数与实际行数相差很大时，应先检查统计信息和数据分布，而不是盲目继续加索引。
自测：从三类查询倒推可能的设计
假设大部分查询都指定一门课程并限定日期，小部分查询只按日期检索全校预约。先提出一个索引方案，并说明还缺什么证据。一个合理起点是 (course, day)，因为它直接匹配主要查询；但是否另建 day 索引，要看次要查询频率、响应要求、数据量与写入成本，不能仅凭“也会查日期”就决定。
再问：SELECT 查询命中三列索引里的筛选字段，是否一定无需读表？答案是否定的。查询投影是否被索引覆盖、数据库的可见性规则及实际执行条件都会影响访问方式。若还要读取索引未保存的备注字段，就不能仅凭筛选条件全部入索引断定只读索引即可。
限制与一页实验记录
小表经常顺序扫描更划算，因为建立和跟随索引路径也有成本；返回大部分记录的查询也未必受益。频繁插入、更新和删除的表需要权衡维护开销。不要把“选择性高的列永远放第一”当成万能规则，等值条件、范围、排序需求和工作负载要一起考虑。
学习实验可记录五项：数据库版本、表规模及数据分布、查询文本、索引定义、计划与测量结果。每次只改变一个主要因素，并保持结果集合一致。本文提供的是理解和验证索引的思路，不是生产系统直接建索引的变更方案；正式变更还需评估锁、空间、回滚与业务影响。
参考资料
下一步
如想练习数据库索引与执行计划，请说明数据库版本、查询条件，以及可以脱敏提供的表结构和计划输出。相关辅导能否安排，取决于学科匹配和导师时间。