关于Join
如上图所示，left join和inner join的取值范围还是有很明显的不同的，看网上不少文章优化left join也不交代上下文环境，直接就是教唆把left join换成inner join，只能说是章口就莱，文体两开花...
关于笛卡尔积
简言之就是强拼，不带条件的硬拼2（多）张表，结果就是直接做乘法
SELECT * FROM a CROSS JOIN b;
SELECT * FROM a INNER JOIN b;
SELECT * FROM a,b;
SELECT * FROM a NATURE JOIN b;
SELECT * FROM a NATURA join b;
如何判断驱动表
如果没有where条件
左连接，如果没有where条件，则左表为驱动表
右连接，如果没有where条件，右表为驱动表
如果有where条件
（参照《数据库索引设计与优化》第8章内容对外表的判定应该是下面写的这个样子）
（参考读书笔记：索引读书笔记）
但是实际操作中有本地谓词的表并不一定百分百的是外表，而是由优化器来判断的
#个人实际优化过程中用的最多的还是下面这条
explain规则：explain语句结果中，第一行为驱动表（该定律适用于join；子查询的话要分情况）
性能优化相关
①选谁做驱动表
引用一个举烂了的例子，在没有过滤条件的情况下，外表有多少行就会被加载多少次；参考《索引设计与优化》这本书的说法，每次加载相当于一次随机读；
假设A表10000行，B表100行；也就是说如果用A表做驱动表会伴随着10000次随机读，而如果是B表作为驱动表，会伴随着100次随机读。
所以普遍的优化方案是小表作为外表（驱动表），用小表去驱动大表。
②创建合理的索引
选择小表驱动大表，然后在内表（被驱动的大表）的连接谓词上建立索引，使得对内表的查询走索引提高效率。这种做法最高效的就是外表是一张小表，而内表的连接谓词刚好是内表的主键。
在对这种没有查询过滤条件的语句执行explain的时候会非常不爽，因为驱动表通常是走的全表扫描；在我的测试中，如果外表上没有查询过滤条件（也就是本地谓词）的话，无论查询项是否是索引项，都是走全表。（换句话说，也就是在没有过滤条件的情况下，外表其实有没有索引对于当前语句的优化意义都不太明显（因为会走全表嘛），如果专门因为某个语句去对外表建一大堆索引的可以省省了）
#用下面的例子来解释上面2句话
m表和t表都是25W行左右，大小差距不大；根据开篇说的驱动表确立规则，无查询过滤条件的左连接，左表为驱动表；蓝框表明了这一点。
绿框的t.charge_no是t表的连接谓词，在这一列上建有一个选择性不错的索引，因此在explain的第二行可以看到内表的查询走了索引，type为ref，效率还算不错。（如果这个连接谓词是t表的主键，效率会更高）
红框处可以看到，对m表取的查询值，我们仅仅取了m.charge_no这一列，而且m.charge_no上是建有索引的，但explain的第一行粉框的ALL表明m表的查询仍然走了全表（即使是我们m表的查询列只取了建有索引的列）。
#如何让外表走索引？
方法：对外表增加过滤条件（本地谓词），并且在本地谓词上创建索引
查询过滤条件中只有t表的本地谓词，因此无论左连接还是右连接，t表都是驱动表
由于过滤条件t.partner_id和t.trade_date上建有索引，因此外表t不再走全表扫描
注意2处蓝框是有关联的，右下角的那个大蓝框里面是没有temporary的，这与接下来讨论的有关
③合理的排序
前面2张图里面的语句是我在项目中遇到的一个慢查询，本体并非前面2张图贴出的那样，区别在于order by后面跟的字段不同，原语句order by后面跟着的是一个内表字段
多表join执行时，优化器内部会先找出外表，之后会对外表进行排序；如果order by后面跟的是外表字段，则排序会在这时完成。但如果order by后面的字段是内表字段，则在所有结果集选出之后，再进行一次排序，这也就是执行计划里面Using temporary的由来了。
项目中的原语句一来没有本地谓词，二来还用内表进行排序，导致最后的执行时间达到8s之久；与研发沟通之后将语句改成用外表字段排序，执行时间所短到0.3s。
④强行指定驱动表
左右连接都可以指定驱动表，但（inner） join无法强行指定，通常来说都是通过系统自动去判定
强行指定方式：straight_join
这个参数会强行指定左表是外表
例子就截个别人的图吧
多表join优化案例
eg.
红框处是可能需要加索引的各种连接谓词和本地谓词，蓝框标示了执行顺序扫描方式等帮助信息
#对执行计划进行分析
在执行计划的第5行可以发现pcb表走了全表扫描，扫描行数达到95W行；通过执行计划的第4行可以发现这里有一个派生表，这个派生表是由pcb和ppv做inner join形成的，这里很明显pcb成了这个连接查询的外表，查询ppv表，发现ppv表仅仅只有19行。这是典型的大表驱动小表
查询pcb表的索引，发现pcb表的连接谓词和本地谓词上面都没有建索引！而ppv.id是ppv表的主键（mysql优化器大概就是因为这个原因让ppv表做了内表吧...）
把pcb表的连接谓词和本地谓词做了一个联合索引之后，扫描行数从95W缩减至5.4W，优化器很识趣的将ppv选做外表了
消灭了95W行的扫描之后，盘面上最刺眼的就是第二行那个2871了，对pc表的索引进行查询发现pc.client_no列上也没有索引，由于pc.client_no列是一个本地谓词，在添加索引之后，pc表直接跳到了explain的第一行。优化后的执行计划如下图
对比pp表和pc表，pp表有16行数据，pc表有3000行数据，都不算太大，无论谁作为驱动表都不会有太大的性能提升了，优化也到此结束；执行时间由1s缩减到0.29s
参考文章
2.《索引设计与优化》
