A. 表连接中的驱动表与被驱动表
mysql中的表连接分为三种
1. 左连接 left join
左连接以左表为基础，查询出左表所有数据并且去匹配右表的数据，如果右表没
有数据，则为空
2. 右连接 right join
右连接以右表为基础，查询出右表所有数据并且去匹配左表的数据，如果左表没
有数据，则为空
3. 内连接 inner join
内连接会把左右表匹配的数据查询出来，不存在的数据直接忽略
驱动表与被驱动表的概念
驱动表是表连接中的基础表，也就是通过驱动表的数据结果集作为循环基础数据，然后一条一条的通过这个结果集的数据作为过滤条件到被驱动表中查询数据，然后合并
驱动与被驱动
左连接中 左表是驱动表，右表是被驱动表
右连接中 右表是驱动表，左表是被驱动表
内连接中 表数据量较小的表会由mysql自动选择作为驱动表去驱动大表
有一个重点是，如果where条件存在的话 mysql会根据where实际条件进行驱动表的选择
sql优化中，一个比较重要的点就是要用小表驱动大表
原因
mysql表关联的算法，是通过驱动表去循环被驱动表，比如说，20w的大表和200条的小表，如果大表驱动，那么是20w条记录外循环，内循环200条去连接查找，需要通过20w次连接，如果小表驱动，那么是200条记录外循环，内循环20w条去连接查找，只需要通过200次连接就可以了，并且驱动表是不会使用索引的
B. sql把最小的表作为驱动表(基础表),为什么能提高效率
驱动表是要全表扫描的，所以记录越少效率就会越高，而且要放在FROM子句中，表名列表的最后。当然这也不是绝对的，很多时候要考虑结果完整性及业务实际需求。
C. mysql在连表查询时是小表驱动大表吗
你那样写逻辑都变化了
假定你要选择的b的field位bf
这昂写就可以了,XXX是要选择的字段列表（不包含b.bf)
SELECT xxx,
CASE b.num WHEN 1 THEN b.bf ELSE NULL END
from a left join b on b.opuid=a.uid
where a.true=1
不知道mysql支持不支持case when，也就是作了一个判断if b.num =1 then b.bf else null
D. SQL执行顺序
查询语句中select from where group by having order by的执行顺序
1.查询中用到的关键词主要包含六个，并且他们的顺序依次为
select--from--where--group by--having--order by
其中select和from是必须的，其他关键词是可选的，这六个关键词的执行顺序
与sql语句的书写顺序并不是一样的，而是按照下面的顺序来执行
from--where--group by--having--select--order by,
from:需要从哪个数据表检索数据
where:过滤表中数据的条件
group by:如何将上面过滤出的数据分组
having:对上面已经分组的数据进行过滤的条件
select:查看结果集中的哪个列，或列的计算结果
order by :按照什么样的顺序来查看返回的数据
2.from后面的表关联，是自右向左解析的
而where条件的解析顺序是自下而上的。
也就是说，在写SQL文的时候，尽量把数据量大的表放在最右边来进行关联，
而把能筛选出大量数据的条件放在where语句的最下面。
SQL Select语句完整的 执行顺序 【从DBMS使用者角度】：
1、from子句组装来自不同数据源的数据；
2、where子句基于指定的条件对记录行进行筛选；
3、group by子句将数据划分为多个分组；
4、使用聚集函数进行计算；
5、使用having子句筛选分组；
6、计算所有的表达式；
7、使用order by对结果集进行排序 。
from 子句--执行顺序为从后往前、从右到左
表名(最后面的那个表名为驱动表，执行顺序为从后往前, 所以数据量较少的表尽量放后）
oracle 的解析器按照从右到左的顺序处理，FROM 子句中的表名，FROM 子句中写在最后的表(基础表 driving
table)将被最先处理，即最后的表为驱动表，在FROM 子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3
个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指被其他表所引用的表
多表连接时，使用表的别名并把别名前缀于每个Column上。可以减少解析的时间并减少那些由Column 歧义引起的语法错误.
where子句--执行顺序为自下而上、从右到左
ORACLE 采用自下而上从右到左的顺序解析Where 子句,根据这个原理,表之间的连接必须写在其他Where 条件之前, 可以过滤掉最大数量记录的条件必须写在Where 子句的末尾。
group by--执行顺序从左往右分组
提高GROUP BY 语句的效率, 可以通过将不需要的记录在GROUP BY 之前过滤掉。即在GROUP BY前使用WHERE来过虑，而尽量避免GROUP BY后再HAVING过滤。
having 子句----很耗资源，尽量少用
避免使用HAVING 子句, HAVING 只会在检索出所有记录之后才对结果集进行过滤. 这个处理需要排序,总计等操作.
如果能通过Where 子句在GROUP BY前限制记录的数目,那就能减少这方面的开销.
(非oracle 中)on、where、having 这三个都可以加条件的子句中，on 是最先执行，where 次之，having 最后，因为on 是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，
where 也应该比having 快点的，因为它过滤数据后才进行sum，在两个表联接时才用on 的，所以在一个表的时候，就剩下where 跟having比较了。
在这单表查询统计的情况下，如果要过滤的条件没有涉及到要计算字段，那它们的结果是一样的，只是where 可以使用rushmore 技术，而having 就不能，在速度上后者要慢。
如果要涉及到计算的字段，就表示在没计算之前，这个字段的值是不确定的，where 的作用时间是在计算之前就完成的，而having 就是在计算后才起作用的，所以在这种情况下，两者的结果会不同。
在多表联接查询时，on 比where 更早起作用。系统首先根据各个表之间的联接条件，把多个表合成一个临时表后，再由where 进行过滤，然后再计算，计算完后再由having 进行过滤。
由此可见，要想过滤条件起到正确的作用，首先要明白这个条件应该在什么时候起作用，然后再决定放在那里。
select子句--少用*号，尽量取字段名称 。
ORACLE 在解析的过程中, 会将依次转换成所有的列名, 这个工作是通过查询数据字典完成的, 使用列名意味着将减少消耗时间。
sql 语句用大写的；因为 oracle 总是先解析 sql 语句，把小写的字母转换成大写的再执行
order by子句--执行顺序为从左到右排序,很耗资源
E. 从哪些方面，sql语句性能如何分析
一段SQL代码写好以后，可以通过查看SQL的执行计划，初步预测该SQL在运行时的性能好坏，尤其是在发现某个SQL语句的效率较差时，我们可以通过查看执行计划，分析出该SQL代码的问题所在。
1、 打开熟悉的查看工具：PL/SQL Developer。
在PL/SQL Developer中写好一段SQL代码后，按F5，PL/SQL Developer会自动打开执行计划窗口，显示该SQL的执行计划。
2、 查看总COST，获得资源耗费的总体印象
一般而言，执行计划第一行所对应的COST(即成本耗费)值，反应了运行这段SQL的总体估计成本，单看这个总成本没有实际意义，但可以拿它与相同逻辑不同执行计划的SQL的总体COST进行比较，通常COST低的执行计划要好一些。
3、 按照从左至右，从上至下的方法，了解执行计划的执行步骤
执行计划按照层次逐步缩进，从左至右看，缩进最多的那一步，最先执行，如果缩进量相同，则按照从上而下的方法判断执行顺序，可粗略认为上面的步骤优先执行。每一个执行步骤都有对应的COST,可从单步COST的高低，以及单步的估计结果集（对应ROWS/基数），来分析表的访问方式，连接顺序以及连接方式是否合理。
4、 分析表的访问方式
表的访问方式主要是两种：全表扫描（TABLE ACCESS FULL）和索引扫描(INDEX SCAN)，如果表上存在选择性很好的索引，却走了全表扫描，而且是大表的全表扫描，就说明表的访问方式可能存在问题；若大表上没有合适的索引而走了全表扫描，就需要分析能否建立索引，或者是否能选择更合适的表连接方式和连接顺序以提高效率。
5、 分析表的连接方式和连接顺序
表的连接顺序：就是以哪张表作为驱动表来连接其他表的先后访问顺序。
表的连接方式：简单来讲，就是两个表获得满足条件的数据时的连接过程。主要有三种表连接方式，嵌套循环（NESTED LOOPS）、哈希连接（HASH JOIN）和排序-合并连接（SORT MERGE JOIN）。我们常见得是嵌套循环和哈希连接。
嵌套循环：最适用也是最简单的连接方式。类似于用两层循环处理两个游标，外层游标称作驱动表，Oracle检索驱动表的数据，一条一条的代入内层游标，查找满足WHERE条件的所有数据，因此内层游标表中可用索引的选择性越好，嵌套循环连接的性能就越高。
哈希连接：先将驱动表的数据按照条件字段以散列的方式放入内存，然后在内存中匹配满足条件的行。哈希连接需要有合适的内存，而且必须在CBO优化模式下，连接两表的WHERE条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。
F. 多表关联查询的SQL执行原理
平时大多是执行单表查询，通常你把索引建好，让他尽可能走索引，性能都没问题。但其实也有不少的多表关联语句，因为有时查找目标数据，不得不借助多表关联的语法，才能实现你想要但使用多表关联的时候，你的SQL性能就可能会遇到一些问题。
若在FROM字句后直接来两个表名，就是要针对两个表进行查询，而且会把两个表的数据给关联，假设你未限定多表连接条件，可能会搞出一个笛卡尔积。所以通常都会在多表关联语句中的WHERE子句里引入一些关联条件：where t1.x1=xxx and t1.x2=t2.x2 and t2.x3=xxx
假设：
所以该SQL执行过程可能是：
他可能是先从一个表里查一波数据：驱动表
再根据这波数据去另外一个表里查一波数据进行关联，另外一个表叫：被驱动表
员工表包含id（主键）、name（姓名）、department（部门）
产品销售业绩表里包含id（主键）、employee_id（员工id）、产品名称（proct_name）、销售业绩（saled_amount）。
现在要看每个员工对每个产品的销售业绩：
此时看到的数据：
全表扫描员工表，找出每个员工，然后针对每个员工的id去业绩表找 employee_id 跟员工id相等的数据，可能每个员工的id在业绩表里都会找到多条数据，因为他可能有多个产品的销售业绩。
然后把每个员工数据跟他在业绩表里找到的所有业绩数据都关联，比如:
内连接，inner join，要求两个表里的数据必须完全能关联上，才能返回。
假设员工表里有个人是新员工，入职到现在无销售业绩，此时还是希望能够查出来该员工的数据，只不过他的销售业绩那块可以给个NULL，表示无业绩。但若仅使用上述SQL语法，似乎搞不定，因为必须要两个表能关联上的数据才查得出来。
此时就需要
outer join，分为：
还有个语法限制，如果你是内连接，那连接条件可以放在where语句，但外连接一般是把连接条件放在ON语句：
一般写多表关联，主要就是内连接和外连接。
G. MySQL表连接之驱动表与被驱动表
众所周知， MySQL的驱动表与被驱动表是优化器自动优化选择的结果 （与表连接的前后顺序等无关），我们可以用explain执行计划来知晓：
如上所示，前面一行t1是驱动表，后面一行t2是被驱动表。那么驱动表与被驱动表的选择是否有规律可循呢？下面是网络搜索两个主流的博文对驱动表与被驱动表的阐释：
1. MySQL连接查询驱动表被驱动表以及性能优化 - 阿伟~ - 博客园 博文A 主要结论：
2. mysql驱动表与被驱动表及join优化_java小小小黑的博客-CSDN博客_mysql驱动表和被驱动表 博文B 其主要结论：
两个帖子的结论是都差不多，而且还给出了例子来佐证。那么网上的结论是否权威？是否有普遍性？是否存在缺陷？
让我们来一起打破砂锅问到底。下面有两张表结构一模一样的表t1,t2：其中t1 100条数据，t2 1000条数据；t1（t2）结构如下：
按照上面博文的结论，left join左边是t2表，应该是驱动表。我们查看下结果：
与 博文B 中观点1相违背（同理观点2也违背），与实际不符，但究竟这是为什么呢？
下面发一张MySQL的执行过程（来源于《MySQL实战45讲》中01讲【一条SQL查询语句是如何执行的】）
so die si ne，原来sql执行的过程是这样呀。等等，不对，这跟刚才SQL又有什么关系，上面left join中t2表还是左边的呀。
我们知道MySQL高版本的性能越来越好，它是不断进行优化迭代的。远古的mysql版本可能还需要人工把小表放在前面，大表放在后面等这些需要人工调优的经验早就已经被解决了。也就是说我们写的语句，MySQL为了追求更好的效率，它在执行器执行前已经帮我们优化了。那么实际优化后的sql如何查看呢？用show warning命令：
其中Message就是优化后实际执行的sql语句，格式化后如下：
优化后left join左连接变成了内连接(inner) join。所以用优化后的sql看，表t1是小表所以作为驱动表，与实际结果相符。
left join 竟然优化成了join,太神奇了，但这是为什么呢？原因在于mysql中null与任何值做等值或者不等值比较的时候都是null，即使是select null=null 也是null。这样where 条件t1.a=t2.a查询条件不会包含t2.a为NULL的行，实际效果其实跟join一样，被优化器智能的优化了。
我们直接看执行计划看实际结果吧：
结果显示t2是驱动表，t1是被驱动表。t2是1000条数据按理说是大表应该是被驱动表，与 博文A ， 博文B 的结论又不一致了。
《MySQL实战45讲》中34讲【到底可不可以使用join】已经讲的很透彻了，很深入了，我就不在这里献丑了。啰嗦几句大概就是驱动表是全表扫描不走索引，所以选被驱动表t1可以走索引，不会全表扫描，减少IO次数，性能高。里面对大表小表的总结，简直是精髓，特意在此再次着重强调：
在决定哪个表做驱动表的时候，应该是两个表按照各自的条件过滤，过滤完成之后，计算参与join的各个字段的总数据量，数据量小的那个表，就是“小表”，应该作为驱动表。
按照上面分析，我们先独立思考下MySQL会选择哪张表作为驱动表呢？
表t1,t2在字段a上都有索引不会全表扫描，其中t1.a=5条件过滤后只有一条，很显然嘛，t1数据量少是小表，肯定是驱动表，错不了，再说了前面的红色粗体已经强调了，不会有错的。
有冇搞错？事实又被打脸了。还记得在开篇我们说过的mysql优化器会对sql语句进行优化的吗？下面我们看下执行计划与优化的sql语句：
格式化后的优化SQL如下：
优化后两表t1,t2都走索引，并且都只有一条结果返回，因此都只会扫描一行，数据量一样，所以谁在前面谁就是驱动表，也就是上面sql中表t2。一切都释然，豁然开通！
回头再仔细想想，高，实在是高！仔细深思之后MySQL优化后的句子真让人猛拍大腿。高明之处在于：
1. 本来join连接是个M*N的嵌套循环，优化后变成了M+N的判断，两表不再嵌套判断了。
2. 优化后，两表没有多大必然联系，只需把两表的结果集拼接即可，互不干扰。如果mysql未来可以多线程查询，岂不十分快哉！
小伙伴们还记得我们在上一章 MySQL索引初探 中编码类型不一致发生隐式转换时有时候走索引，有时候索引又失效的问题吗？下面我们选取有代表性的一条记录来分析：
其中表demo_test总共有640条数据，demo_test_ass有3条数据。显然经过过滤条件t.rid>1完成后demo_test_ass数据量小，应该作为驱动表。虽然test.c_utf8mb4 = t.c2两字段连接中发生了t.c2字段发生隐式转换，但是实际上并不影响被驱动表test上的c_utf8mb4索引。
好了，本章到此结束，让我们一起 总结一下MySQL驱动表与被驱动表的选取原则 ：
หน ง 同等条件，优先选取有索引的表作为被驱动表。 在此介绍一下什么叫同等条件，比如上面的②中的语句。 两表没有其他额外的过滤条件，因此选关联字段有索引的t1作为被驱动表。但是如果加了条件(and t1.id=3)，此时t1数据量少，就选取了t2作为被驱动表。
สอง MySQL选择驱动表与被驱动表是基于优化器优化后的，小表是驱动表，大表是被驱动表。 基于优化器优化后开篇的 博文A与B 结论成立。
当然这都是我一家之言，并不是官方结论，目前暂未找到官方确切对于驱动表与被驱动表的解释，请大家踊跃拍砖！
H. 优化SQL语句
一.常规SQL语句优化
1.不用*来代替所有列名，尽量采用与访问表相关的实际列名；
2.用TRUNCATE 代替DELETE
3.在确保完整性的情况下，多使用COMMIT语句。
4.尽量减少表的查询次数。
二.表连接优化
1.驱动表的选择：
驱动表是指被最先访问的表；
2.where子句连接顺序
表连接最好都在where条件以前
三.合理使用索引
从总行中查询2%-4%的表，可以考虑建立索引
建立索引的基本原则：
1.以查询关键字为基础，表中的行随机排列
2.包含的列数相对较少的表
3.表中大多数查询都包含相对简单的WHERE从句
4.以查询关键字作为基础表，且该表中的行遵循均匀分布
5.缓存命中率低，并且不需要操作系统权限
选择索引列的原则：
1.WHERE从句经常使用的关键字
2.SQL语句中频繁使用的表连接的关键字
3.可选择性高的关键字
4.取值较少的关键字或表达式
5.不要把频繁修改的列作为索引列
6.不要使用包含操作符或函数的WHERE从句中的关键字作为索引
7.如果大量并发的INSERT,UPDATE,DELETE语句访问了父表或者子表，则考虑使用完整性约束的外部键作为索引
8.在选择索引时，要考虑改索引所引起的INSERT UPDATE,DELETE操作是否值得
I. 13.MySQL联表查询中的驱动表，优化查询，以小表驱动大表
=========================总结===========================
1.开启慢查询日志，设置阀值，比如超过5秒就是慢SQL,并把它抓取出来。
2.explain+慢SQL 分析
3.show profile 查询SQL在MySQL服务器里面的执行细节和声明周期。
J. sql中in和exist语句的区别
两者都能实现表功能查询，主要区别如下：
1、适用表的类型不同。
in是子查询为驱动表，外面的表为被驱动表，故适用于子查询结果集小而外面的表结果集大的情况。
exists是外面的表位驱动表，子查询里面的表为被驱动表，故适用于外面的表结果集小而子查询结果集大的情况。
2、子查询关联不同。
exists一般都是关联子查询。对于关联子查询，必须先执行外层查询，接着对所有通过过滤条件的记录，执行内层查询。外层查询和内层查询相互依赖，因为外层查询会把数据传递给内层查询。
in则一般都是非关联子查询，非关联子查询则必须先完成内层查询之后，外层查询才能介入。
3、执行次数不同。
IN 语句：只执行一次，确定给定的值是否与子查询或列表中的值相匹配。in在查询的时候，首先查询子查询的表，然后将内表和外表做一个笛卡尔积，然后按照条件进行筛选。所以相对内表比较小的时候，in的速度较快。
EXISTS语句：执行次数根据表的长度而定。指定一个子查询，检测行的存在。遍历循环外表，然后看外表中的记录有没有和内表的数据一样的。匹配上就将结果放入结果集中。