在业务中，涉及到两个或多个表联查的时候，我们通常会使用join把表的行结合起来。
SQL中的join可以根据某些条件把指定的表给结合起来并将数据返回给客户端。
join的方式有
-
inner join内连接
-
left join左连接
-
right join右连接
-
full join全连接
在项目开发中如果需要使用join语句，如何优化提升性能?
可以根据数据规模分为两种情况，数据规模小的，数据规模大的。
对于
数据规模较小 全部干进内存就可以了
数据规模较大
可以通过增加索引来优化
join语句的执行速度 ，可以通过冗余信息来减少join的次数， 尽量减少表连接的次数，一个SQL语句表连接的次数不要超过5次
join语句是相对比较耗费性能
在执行join语句的时候必然要有一个比较的过程
逐条比较两个表的语句是比较慢的，因此我们可以把两个表中数据依次读进一个内存块中, 以MySQL的InnoDB引擎为例，使用以下语句我们必然可以查到相关的内存区域show variables like '%buffer%'
如下图所示join_buffer_size的大小将会影响我们join语句的执行性能
一个大前提
任何项目终究要上线，不可避免的要产生数据，数据的规模又不可能太小
大部分数据库中的数据最终要保存到硬盘上,并且以文件的形式进行存储。
以MySQL的InnoDB引擎为例
InnoDB以
页(page)为基本的IO单位，每个页的大小为16KBInnoDB会为每个表创建用于存储数据的
.ibd文件
验证
这意味着我们有多少表要连接就需要读多少个文件，虽然可以利用索引，但还是免不了频繁的移动硬盘的磁头。
也就是说频繁的移动磁头会影响性能。
现在的开源框架不都喜欢说自己通过顺序读写大大的提升了性能吗，比如hbase、kafka。
执行一次free命令看一下
total 总内存
used 已用内存
free 空闲内存
buff/cache 已使用的缓存
avaiable 可用内存
会发现缓存怎么占用了1.2G多
现在又有几个问题？
buff/cache里面存的是什么？为什么
buff/cache占了那么多内存，可用内存即availlable还有1.1G？为什么你可以通过两条命令来清理
buff/cache占用的内存，而想要释放used只能通过结束进程来实现?
在《CSAPP》（深入理解计算机系统）里面有这样一句话：
存储器层次结构的本质是，每一层存储设备都是较低一层设备的缓存
简单的说，就是Linux会把内存当作是硬盘的高速缓存
Join算法
如果让你来实现Join算法你会怎么做?
无索引的话，就嵌套循环
有索引的话，则可以利用索引来提升性能。
join_buffer里面存储的是什么?
在扫描过程中，数据库会选择一个表把他要返回以及需要进行和其他表进行比较的数据放进join_buffer。
有索引的情况下是怎么处理的？
直接读取两个表的索引树进行比较
下面介绍一下无索引的处理方式：
Nested Loop Join
嵌套循环，每次只读取表中的一行数据，也就是说如果outerTable有10万行数据, innerTable有100行数据，需要读取10000000次(假设这两个表的文件没有被操作系统给缓存到内存, 我们称之为冷数据表)
当然现在没啥数据库引擎使用这种算法（太慢了)
Block nested loop
Block 块，也就是说每次都会取一块数据到内存以减少I/O的开销。
当没有索引可以使用的时候，MySQL InnoDB 就会使用这种算法。
考虑以下两个表 t_a 和t_b
当无法使用索引执行join操作的时候，InnoDB会自动使用Block nested loop 算法。
总结
上学时，数据库老师最喜欢考数据库范式，直到上班才学会一切以性能为准，能冗余就冗余，实在冗余不了的就join。
如果join真的影响到性能，试着调大你的join_buffer_size, 或者换固态硬盘。
