IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

标签:hash join

共 2 篇相关文章

IT 累计浏览 2,613

MariaDB数据库5.5.27 HASH JOIN源码解读

这篇讲的是MariaDB 5.5.27版本中HASH JOIN特性的底层源码实现。作者从MySQL与MariaDB的分支差异切入,指出MariaDB为优化等值JOIN性能而引入了该特性,并深入其C++源码,拆解了从优化器决策到执行器运行的全过程。 文章的核心在于剖析HASH JOIN的执行逻辑:它如何为内表建立内存哈希表,再逐行探测外表以完成连接。作者特别指出了几个巧妙的设计点,比如在内存压力较大时,系统如何自动切换为分片处理模式,将哈希表溢出写入磁盘,从而在有限资源下完成大表连接。同时,文中也对比了其与MySQL原有Block Nested Loop算法的效率差异,并提供了实际执行计划的对比分析。 对于想理解数据库连接算子如何从算法落地到具体代码的读者,这篇源码解读提供了一个清晰的范本,展示了工程实现中如何在性能与资源间做权衡。

IT 累计浏览 4,237

Oracle hash join

这篇讲的是Oracle中hash join的运作原理,它被作者称为一个“非常强悍的功能”。文章没有停留在理论,而是直白地剖析了其核心流程:Oracle首先会选择一个表作为驱动表,根据过滤条件进行筛选,然后将结果集构建成一个哈希表存放在进程的PGA内存(hash area)中。接着,它再去扫描第二张表,对每一行的键值进行哈希运算,并到内存的哈希表中去“探测”,命中则返回数据,否则丢弃。 但文章的重点不止于此。作者紧接着点出了关键现实约束:考虑到单个进程PGA内存的大小,Oracle并不会允许无限制地消耗系统内存。因此,这个看似直接的过程在Oracle内部实际上被细化为三种不同的执行模式。这恰恰解释了在不同数据规模或内存条件下,查询计划为什么会发生差异。 文章从原理讲到内存限制的现实考量,为读者勾勒出一个更立体的hash join图景,其细节对于理解数据库性能和配置背后的逻辑很有启发。