技术分享 | MySQL 的 join_buffer_size 在内链接上的应用

做者：杨涛涛

本文详细介绍了 MySQL 参数 join_buffer_size 在 INNER JOIN 场景的使用，OUTER JOIN 不包含。在讨论这个 BUFFER 以前，咱们先了解下 MySQL 的 INNER JOIN 分类。

若是按照检索的性能方式来细分，那么不管是两表 INNER JOIN 仍是多表 INNER JOIN，都大体能够分为如下几类：

1.JOIN KEY 有索引，主键
2.JOIN KEY 有索引， 二级索引
3.JOIN KEY 无索引

今天主要针对第三种场景来分析，也是就全表扫的场景。

回过头来看看什么是 join_buffer_size？

JOIN BUFFER 是 MySQL 用来缓存以上第2、第三这两类 JOIN 检索的一个 BUFFER 内存区域块。通常建议设置一个很小的 GLOBAL 值，完了在 SESSION 或者 QUERY 的基础上来作一个合适的调整。好比 默认的值为 512K， 想要临时调整为 1G，那么

mysql>set session join_buffer_size = 1024 * 1024 * 1024; 
mysql>select * from ...;    
mysql>set session join_buffer_size=default;    
或者
mysql>select /*+  set_var(join_buffer_size=1G) */ * from ...;

接下来详细看下 JOIN BUFFER 的用法。那么 MySQL 里针对 INNER JOIN 大体有如下几种算法，

1. Nested-Loop Join 翻译过来就是嵌套循环链接，简称 NLJ。

这种是 MySQL 里最简单的，最容易理解的表关联算法。

好比拿语句 select * from p1 join p2 using (r1) 来讲，

先从表 p1 里拿出来一条记录 ROW1，完了再用 ROW1 遍历表 p2 里的每一条记录，而且字段 r1 来作匹配是否相同以便输出；再次循环刚才的过程，直到两表的记录数对比完成为止。

那看下实际 SQL 的执行计划

mysql> explain format=json select * from p1 inner join p2 as b using(r1)\G
*************************** 1. row ***************************
EXPLAIN: {
 "query_block": {
   "select_id": 1,
   "cost_info": {
     "query_cost": "1003179606.87"
   },
   "nested_loop": [
     {
       "table": {
         "table_name": "b",
         "access_type": "ALL",
         "rows_examined_per_scan": 1000,
         "rows_produced_per_join": 1000,
         "filtered": "100.00",
         "cost_info": {
           "read_cost": "1.00",
           "eval_cost": "100.00",
           "prefix_cost": "101.00",
           "data_read_per_join": "15K"
         },
         "used_columns": [
           "id",
           "r1",
           "r2"
         ]
       }
     },
     {
       "table": {
         "table_name": "p1",
         "access_type": "ALL",
         "rows_examined_per_scan": 9979810,
         "rows_produced_per_join": 997981014,
         "filtered": "10.00",
         "cost_info": {
           "read_cost": "5198505.87",
           "eval_cost": "99798101.49",
           "prefix_cost": "1003179606.87",
           "data_read_per_join": "14G"
         },
         "used_columns": [
           "id",
           "r1",
           "r2"
         ],
         "attached_condition": "(`ytt_new`.`p1`.`r1` = `ytt_new`.`b`.`r1`)"
       }
     }
   ]
 }
}
1 row in set, 1 warning (0.00 sec)

从上面的执行计划来看，表 p2 为第一张表（驱动表或者叫外表），第二张表为 p1，那 p2 须要遍历的记录数为 1000，同时 p1 须要遍历的记录数大概 1000W 条，那这条 SQL 要执行完成，就得对表 p1（内表）匹配 1000 次，对应的 read_cost 为 5198505.87。那如何才能减小表 p1 的匹配次数呢？那这个时候 JOIN BUFFER 就派上用处了

2. Block Nested-Loop Join ，块嵌套循环，简称 BNLJ

那 BNLJ 比 NLJ 来讲，中间多了一块 BUFFER 来缓存外表的对应记录从而减小了外表的循环次数，也就减小了内表的匹配次数。仍是那上面的例子来讲，假设 join_buffer_size 恰好能容纳外表的对应 JOIN KEY 记录，那对表 p2 匹配次数就由 1000 次减小到 1 次，性能直接提高了 1000 倍。

咱们看下用到 BNLJ 的执行计划

mysql> explain format=json select * from p1 inner join p2 as b using(r1)\G
*************************** 1. row ***************************
EXPLAIN: {
 "query_block": {
   "select_id": 1,
   "cost_info": {
     "query_cost": "997986300.01"
   },
   "nested_loop": [
     {
       "table": {
         "table_name": "b",
         "access_type": "ALL",
         "rows_examined_per_scan": 1000,
         "rows_produced_per_join": 1000,
         "filtered": "100.00",
         "cost_info": {
           "read_cost": "1.00",
           "eval_cost": "100.00",
           "prefix_cost": "101.00",
           "data_read_per_join": "15K"
         },
         "used_columns": [
           "id",
           "r1",
           "r2"
         ]
       }
     },
     {
       "table": {
         "table_name": "p1",
         "access_type": "ALL",
         "rows_examined_per_scan": 9979810,
         "rows_produced_per_join": 997981014,
         "filtered": "10.00",
         "using_join_buffer": "Block Nested Loop",
         "cost_info": {
           "read_cost": "5199.01",
           "eval_cost": "99798101.49",
           "prefix_cost": "997986300.01",
           "data_read_per_join": "14G"
         },
         "used_columns": [
           "id",
           "r1",
           "r2"
         ],
         "attached_condition": "(`ytt_new`.`p1`.`r1` = `ytt_new`.`b`.`r1`)"
       }
     }
   ]
 }
}
1 row in set, 1 warning (0.00 sec)

上面的执行计划有两点信息，

第一：多了一条 "using_join_buffer": "Block Nested Loop"

第二：read_cost 这块由以前的 5198505.87 减小到 5199.01

3. 最近 MySQL 8.0.18 发布，终于推出了新的 JOIN 算法 — HASH JOIN。

MySQL 的 HASH JOIN 也是用了 JOIN BUFFER 来作缓存，可是和 BNLJ 不一样的是，它在 JOIN BUFFER 中之外表为基础创建一张哈希表，内表经过哈希算法来跟哈希表进行匹配，hash join 也就是进一步减小内表的匹配次数。固然官方并无说明详细的算法描述，以上仅表明我的臆想。那仍是针对以上的 SQL，咱们来看下执行计划。

mysql> explain format=tree select * from p1 inner join p2 as b using(r1)\G
*************************** 1. row ***************************
EXPLAIN: -> Inner hash join (p1.r1 = b.r1)  (cost=997986300.01 rows=997981015)
   -> Table scan on p1  (cost=105.00 rows=9979810)
   -> Hash
       -> Table scan on b  (cost=101.00 rows=1000)

1 row in set (0.00 sec)

经过上面的执行计划看到，针对表 p2 创建一张哈希表，而后针对表 p1 来作哈希匹配。

目前仅仅支持简单查看是否用了 HASH JOIN，而没有其余更多的信息展现。

总结下，本文主要讨论 MySQL 的内表关联在没有任何索引的低效场景。其余的场景另外开篇。