数据库索引

索引如何用额外空间加快查询？

• 索引: 保存查询键与数据位置之间的辅助结构，可以类比书的目录，避免每次查找都遍历所有记录;
• 查询路径: 根据索引键定位候选记录，再按需读取完整数据，索引顺序也能帮助排序与范围访问;
• 单列与多列: 可以索引一个或多个列，多列索引要与实际过滤及排序方式匹配;
• 读取收益: 同一份数据能拥有多种访问顺序，不必为每种查询完整复制一份业务表;
• 写入代价: 插入、修改或删除数据时还需维护相关索引，索引越多，写放大和空间成本越高;

稠密索引如何定位每条记录？

• 稠密索引: 为每条记录或每个搜索键值提供相应索引入口，使查询直接找到候选数据位置;
• 优点: 查找路径直接，原文示意模型不要求底层数据按该索引顺序排列;
• 代价: 索引项较多，占用更多存储，记录增删改也更常触发索引维护;
• 实现边界: 真实数据库可能让同一键指向多条记录，不能把“一条索引项”机械等同于“一整行业务数据”;

索引键 10 → 记录 A
索引键 20 → 记录 B
索引键 30 → 记录 C

稀疏索引怎样用更少入口定位范围？

• 稀疏索引: 只保存部分搜索键或块入口，先定位可能包含目标的范围，再扫描该范围;
• 顺序前提: 原文这种教材模型需要数据按搜索键有序，才能从前一个入口推断后续范围;
• 收益: 更少的索引项降低空间与维护成本;
• 代价: 查到入口后仍可能读取或扫描数据页，不能把二分定位入口等同于直接获得目标记录;

索引键 10 → 数据块 [10, 12, 18]
索引键 20 → 数据块 [20, 24, 29]
查找 24 → 找到入口 20 → 扫描该块

何时新增索引才值得？

• 依据: 查看高频查询实际过滤、排序和访问行数，优先帮助真正昂贵的访问路径;
• 反例: 写密集表上为每个字段建索引，可能让整体更慢而没有可观的读收益;
• 验证: 比较代表性负载下的执行计划、查询延迟、写入延迟和空间占用;