数据库b+树索引与哈希索引

### 数据库中 B+ 树索引与哈希索引的区别

#### 1. 结构差异
B+树索引采用一种多路平衡查找树的数据结构，所有的叶子节点都位于同一层，并且这些节点之间存在链表连接。这种设计使得B+树不仅支持快速的等值查询，还非常适合范围查询操作[^1]。

相比之下，哈希索引则是利用散列函数将记录的关键字映射到特定位置上形成的一种索引方式。由于其工作原理决定了只有当键完全相等时才能定位到对应的行数据，因此不适用于范围扫描或部分匹配的情况[^5]。

#### 2. 查询效率对比
对于单条记录的精准查找而言，如果不存在大量冲突（即多个不同关键字被映射到了同一个地址），那么理论上讲哈希索引可以达到O(1)的时间复杂度，而B+树则通常为O(log n)[^4]。然而，在实际应用环境中，考虑到可能存在的哈希碰撞以及随之带来的额外处理开销，两者的性能差距往往并没有理论分析得那么明显。

另外值得注意的是，随着表内数据量的增长，维护一个高效的哈希索引所需的空间也会相应增加，这可能导致内存占用过高甚至溢出等问题的发生；相反地，B+树能够较好地适应大规模数据集并保持相对稳定的访问速度[^3]。

#### 3. 更新成本考量
每当向数据库插入新元组或者删除已有元组时，都需要同步更新相应的索引信息。就这一点来说，B+树相较于哈希索引拥有更低廉的成本——前者仅需调整局部子树即可完成任务，后者却有可能因重新计算整个哈希表而导致较高的时间消耗[^2]。

### 应用场景推荐

- **适合使用B+树索引的情形**
- 需要频繁执行区间查询、排序输出的操作；
- 表结构经常变动，如增删改查频率较高；
- 关心整体读写性能而非单纯追求某类特殊查询的速度优势。

- **更适合部署哈希索引的情境**
- 主要是针对唯一性约束字段实施高效检索；
- 当前业务逻辑主要围绕着固定模式下的精确匹配展开；
- 对象集合规模较小且不易发生变化，从而减少重建索引所带来的资源浪费风险。

-- 创建带有B+树索引的表格实例
CREATE TABLE employees (
    id INT NOT NULL,
    name VARCHAR(50),
    department_id INT,
    PRIMARY KEY (id), -- 默认创建B+树索引
    INDEX idx_department (department_id) USING BTREE -- 显式指定使用B+树作为索引类型
);

-- 构建哈希索引的例子
CREATE TABLE user_accounts (
    account_number CHAR(8) NOT NULL,
    balance DECIMAL(10, 2),
    PRIMARY KEY (account_number) USING HASH -- 使用哈希算法构建主键索引
);