数据库索引选择：B树与哈希的差异
数据库索引选择：B树与哈希的差异
数据库查询速度的瓶颈常源于索引策略不当。B树与哈希索引是两种核心结构，理解它们的差异，是精准选择索引、优化查询性能的关键。本文从原理与场景出发，剖析B树与哈希索引的适用边界。
核心差异：有序性与等值查找
B树索引：范围查询的基石
B树是一种平衡多路搜索树，节点内存储多个键值，且保持键的有序排列。这种结构让B树天生擅长范围查询，例如“查询销售额在1000到5000元之间的订单”。B树通过中序遍历能高效定位起始键，并连续扫描后续节点，无需全表扫描。
哈希索引：等值匹配的利器
哈希索引基于哈希函数将键映射到固定长度的桶中。等值查询时，直接计算哈希值定位数据，时间复杂度接近O(1)，速度极快。但哈希表是无序的，无法支持范围查询（如“大于某值”），也无法用于排序操作。此外，哈希冲突会降低性能，而B树的树高增长相对可控。
应用场景选择：B树与哈希的差异
何时选择B树
B树索引适合以下场景：频繁执行范围查询（如时间区间、价格区间）、需要排序操作（ORDER BY）、或涉及前缀匹配的模糊查询（如LIKE ‘abc%’）。MySQL的InnoDB引擎默认使用B+树（B树变种），直接支持范围扫描与联合索引的最左前缀原则。
何时选择哈希
哈希索引在等值查询频繁且数据分布均匀的场景中表现优异。例如，用户登录验证（根据唯一ID查密码）、缓存系统（如Redis的哈希结构）。但需注意，哈希索引无法支持部分键匹配（如联合索引中跳过最左列），且不适合高并发写入时大量哈希冲突的场景。
性能权衡：磁盘I/O与内存开销
B树的磁盘友好性
B树节点通常设计为磁盘页大小（如4KB-16KB），通过减少树的高度（常见为3-4层）来降低磁盘I/O次数。对于大规模数据，B树能利用局部性原理缓存热点节点，提升连续访问效率。
哈希的内存依赖
哈希索引需要将整个哈希表加载到内存中才能保证高效查找。若数据量超过内存容量，哈希冲突和磁盘交换将严重拖慢性能。因此，哈希索引更适合内存数据库或明确知道数据量可控的场景。
总结：根据查询模式选择索引
数据库索引选择：B树与哈希的差异本质在于有序性与等值查找的取舍。B树适合范围查询、排序与部分匹配场景，是大多数关系型数据库的默认选择；哈希索引则专攻等值查询，在内存充足时能提供极致速度。实际应用中，需分析业务查询模式——若80%查询为等值查找，可考虑哈希索引；若混合存在范围、排序需求，B树更稳妥。理解差异，才能在索引设计时避免性能陷阱。