索引结构与访问路径
061 B-tree 索引适合哪些查询？
难度： 基础
- A. 等值、范围、排序与去重等常规场景
- B. 只能加速等值查询
- C. 适合模糊搜索的任意子串
- D. 只支持整数列
查看答案与解析
正确答案A
正确原因： B-tree 保持键有序，等值、范围、ORDER BY 与 DISTINCT 都可利用。
关键边界： 任意子串模糊匹配需要 pg_trgm 或全文索引。
错误选项辨析： B-tree 支持范围与排序，支持多种类型，但子串匹配不是强项。
062 复合索引 (a, b, c) 上，哪种 WHERE 通常无法使用该索引？
难度： 进阶
- A. WHERE b = ? AND c = ?（跳过前导列 a）
- B. WHERE a = ? AND b = ?
- C. WHERE a = ? AND b = ? AND c = ?
- D. WHERE a = ? ORDER BY b
查看答案与解析
正确答案A
正确原因： PostgreSQL 也遵循最左前缀，跳过前导列时该复合索引无法定位。
关键边界： 规划器可能用 Index Skip Scan（PG 18 新特性）补偿部分场景，但不等同于可用。
错误选项辨析： 含前导列 a 的组合才可能使用该索引。
063 Index Only Scan 为什么有时还要回表？
难度： 进阶
- A. 索引没有存储任何键值
- B. 可见性映射缺失时需检查实际行版本，无法完全免回表
- C. 回表是为了给索引排序
- D. 只有主键才能免回表
查看答案与解析
正确答案B
正确原因： 仅索引扫描依赖可见性映射判断行可见性，映射缺失或行不冻结时会回表。
关键边界： VACUUM 维护可见性映射，能显著提高仅索引扫描命中率。
错误选项辨析： 索引存有键值，回表是可见性检查而非排序，二级索引同样可仅索引扫描。
064 对索引列使用函数（如 WHERE lower(email) = ?）会发生什么？
难度： 基础
- A. 索引一定照常使用
- B. 普通 B-tree 无法使用，需要为表达式建立函数索引
- C. 查询一定报错
- D. 函数会加速索引查找
查看答案与解析
正确答案B
正确原因： 对列做函数变换后键不匹配，普通索引失效，需对表达式建索引。
关键边界： 表达式索引要与查询表达式完全一致才能命中。
错误选项辨析： 不会自动使用，不会报错，函数本身不加速。
065 PostgreSQL 中 WHERE int_col = ‘123’（字符串字面量）会发生什么？
难度： 进阶
- A. 像 MySQL 一样隐式转换导致索引失效
- B. 直接报类型错误
- C. 字面量被转换为整数列类型，索引通常可用
- D. 必须显式写 CAST 才能执行
查看答案与解析
正确答案C
正确原因： PG 会把字符串字面量转换为列类型再比较，不破坏索引键。
关键边界： 若列是文本而参数是数值，PG 通常也按列类型转换字面量。
错误选项辨析： 这是与 MySQL 隐式转换差异的经典考点，PG 不报错也不需要显式 CAST。
066 GIN 索引适合哪些场景？
难度： 基础
- A. 整数等值与范围排序
- B. 几何最近邻查询
- C. 数组包含、JSONB 键值与全文检索等多值匹配
- D. 只支持单值列
查看答案与解析
正确答案C
正确原因： GIN 为多值类型设计，支持数组、JSONB 与全文检索的包含操作。
关键边界： 写入代价较高，适合读多写少的查询。
错误选项辨析： 等值范围用 B-tree，最近邻用 GiST，GIN 面向多值。
067 GiST 索引适合哪些场景？
难度： 进阶
- A. 普通整数等值查询
- B. 数组包含查询
- C. 布尔列去重
- D. 范围类型、几何数据与最近邻搜索
查看答案与解析
正确答案D
正确原因： GiST 是可扩展索引框架，支持范围重叠、几何相交与 kNN 查询。
关键边界： 不同操作符类的性能差异较大，需按查询选择。
错误选项辨析： 等值数组用 GIN，普通等值用 B-tree，布尔列低选择性不宜建索引。
068 BRIN 索引适合什么数据？
难度： 进阶
- A. 频繁随机更新的小表
- B. 任意一张普通业务表
- C. 只有 JSONB 字段的表
- D. 数据量与物理顺序高度相关的大表，如按时间追加的日志表
查看答案与解析
正确答案D
正确原因： BRIN 记录块范围的摘要，顺序相关的大表扫描少量块即可排除大量数据。
关键边界： 数据无序或更新频繁时 BRIN 收益低，且需要二次确认。
错误选项辨析： 小表收益有限，随机更新破坏相关性，BRIN 不限于 JSONB。
069 部分索引（Partial Index）的作用是？
难度： 进阶
- A. 只对满足 WHERE 条件的行建索引，更小更快
- B. 索引所有行但只保留部分列
- C. 对索引结果加密
- D. 把表拆分成多个物理文件
查看答案与解析
正确答案A
正确原因： 部分索引用 WHERE 限定索引行集，适合只查询特定子集的数据。
关键边界： 查询条件必须包含与索引条件兼容的谓词才能命中。
错误选项辨析： 部分索引按行过滤而非列，不加密、不拆表。
070 为 lower(email) 建索引后，查询命中条件是？
难度： 基础
- A. 查询必须同样使用 lower(email) 表达式
- B. 任何 email 查询都自动命中
- C. 只能命中完全相等的原值
- D. 需要额外加全文索引
查看答案与解析
正确答案A
正确原因： 表达式索引与查询表达式逐一匹配，写法不一致就失效。
关键边界： 函数索引也可用于约束唯一性。
错误选项辨析： 不自动命中，不限于原值，与全文索引无关。
071 INCLUDE 子句在索引中的作用是？
难度： 进阶
- A. 让附列参与最左前缀匹配
- B. 把附列加入索引但不参与排序，支持仅索引扫描
- C. 把附列变成主键
- D. 给索引加密
查看答案与解析
正确答案B
正确原因： INCLUDE 列存储在叶子节点，不参与键排序，用于覆盖查询列。
关键边界： 适合查询固定附加列的场景，减少回表。
错误选项辨析： INCLUDE 列不参与前缀匹配，不是主键，也不加密。
072 多个单列索引通过 AND 组合时，规划器可能？
难度： 进阶
- A. 只允许使用其中一个索引
- B. 用 Bitmap 位图扫描合并多个索引的结果
- C. 必须新建复合索引否则报错
- D. 多个单列索引永远比复合索引快
查看答案与解析
正确答案B
正确原因： PG 可对多个单列索引做 Bitmap AND/OR，先合并位图再取行。
关键边界： 高频组合过滤场景仍建议按模式设计复合索引。
错误选项辨析： 可以合并使用，不需要复合索引才能执行，复合索引更紧凑。
073 ORDER BY col DESC NULLS LAST 需要什么配合？
难度： 进阶
- A. 索引无法影响排序
- B. NULLS LAST 只能用于聚合
- C. 索引排序方向与 NULL 位置与查询一致时才能免排序
- D. 必须禁用索引才能排序
查看答案与解析
正确答案C
正确原因： PG 索引可声明 ASC/DESC 与 NULLS FIRST/LAST，与查询一致时走索引序。
关键边界： 反向扫描可处理部分反向排序，但 NULL 位置需要匹配。
错误选项辨析： 索引可以避免排序，NULLS 是索引定义的一部分，不需要禁用索引。
074 唯一约束与唯一索引的关系是？
难度： 基础
- A. 两者完全不同，不能同时存在
- B. 唯一索引不保证唯一性
- C. 唯一约束会自动创建唯一索引，但语义上多一层约束管理
- D. 唯一约束不产生任何索引
查看答案与解析
正确答案C
正确原因： 创建 UNIQUE 约束时 PG 自动建立对应唯一索引，NULL 语义一致。
关键边界： 直接用 CREATE UNIQUE INDEX 可配合部分索引实现条件唯一。
错误选项辨析： 约束与索引同源，唯一索引保证唯一，约束必然建索引。
075 索引膨胀后，推荐的维护手段是？
难度： 进阶
- A. 只能删除整张表
- B. 膨胀会自动消失无需处理
- C. 运行 VACUUM FULL 之外的任何命令
- D. REINDEX 重建索引，回收碎片并缩小体积
查看答案与解析
正确答案D
正确原因： REINDEX 重建索引消除膨胀，在线环境可用 CONCURRENTLY。
关键边界： 更新频繁的表会持续产生膨胀，需配合监控定期维护。
错误选项辨析： 膨胀不会自愈，不必删表，REINDEX 是标准手段。
076 生产环境对大表建索引，更安全的做法是？
难度： 实战
- A. 直接 CREATE INDEX，锁表最短
- B. 先删表再建索引
- C. 在事务中反复尝试
- D. CREATE INDEX CONCURRENTLY，不阻塞写入
查看答案与解析
正确答案D
正确原因： CONCURRENTLY 允许 DML 继续，代价是更慢且不能放在事务块中。
关键边界： 失败可能留下无效索引，需检查 indisvalid 并清理。
错误选项辨析： 普通 CREATE INDEX 会锁表，删表不可行，事务内不可用 CONCURRENTLY。
077 低选择性列（如性别）建索引，优化器通常？
难度： 基础
- A. 估算扫描行数过大时选择全表扫描，索引形同虚设
- B. 一定会使用该索引
- C. 索引会让写入更快
- D. 选择性不影响计划
查看答案与解析
正确答案A
正确原因： 优化器按选择性估算成本，返回大部分行时顺序扫描更便宜。
关键边界： 除非查询只取少数行或配合部分索引，否则收益有限。
错误选项辨析： 建索引不保证被用，索引增加写入成本，选择性是决策核心。
078 需要按前缀模糊搜索（如 name LIKE ‘abc%’），可用的方案是？
难度： 进阶
- A. 任何 LIKE 都无法使用索引
- B. B-tree 前缀匹配或 pg_trgm 扩展支持更灵活的模糊搜索
- C. 只能用全文索引替代
- D. 必须全表扫描
查看答案与解析
正确答案B
正确原因： B-tree 支持前缀匹配，pg_trgm 用 GIN/GiST 支持中间与后缀匹配。
关键边界： 任意子串匹配必须借助 pg_trgm 或全文检索。
错误选项辨析： 前缀 LIKE 可用 B-tree，pg_trgm 覆盖更广场景，不需要全表扫描。
079 哈希索引在 PostgreSQL 中适用于？
难度： 进阶
- A. 范围查询与排序
- B. 模糊匹配
- C. 大表的等值查询，且 WAL 安全后已被多数场景接受
- D. 任何查询都优于 B-tree
查看答案与解析
正确答案C
正确原因： 哈希索引支持等值查找，PG 10 后具备 WAL 与复制支持。
关键边界： 不支持范围与排序，通用场景 B-tree 仍是默认选择。
错误选项辨析： 哈希不适合范围与排序，也不全面优于 B-tree。
080 加索引后查询没有变快，排查第一步是？
难度： 实战
- A. 直接重建整个数据库
- B. 删除所有旧索引
- C. 重启数据库清空缓存
- D. 用 EXPLAIN 确认是否真的使用新索引以及估算行数
查看答案与解析
正确答案D
正确原因： 执行计划决定是否使用索引，结合 rows 与统计信息判断原因。
关键边界： 可能是选择性低、统计过旧或查询写法不匹配。
错误选项辨析： 重启、删索引、重建库都不是诊断手段。