有什么做礼品的卖家网站/近期国内新闻热点事件

场景描述

以一个场景为例：

单据A：下游子表 （数据量级小）
单据B：下游主表（数据量级小）
单据C：中游子表（数据量级小）
单据D：中游主表（数据量级小）
单据E：上游子表（数据量级小）
单据F：上游主表（比其他表数据量级大）

需求：将单据F的某个字段，刷到单据A的某个字段上面。从A到F，都可以通过id连接索引的形式，来关联。但是A到F的连接顺序必须是从A到F顺序连接。比如：

这几个表的连接可以用下面的例子演示：

a join b on a.id = b.id
b join c on b.id = c.mainId
c join d on c.id = d.tableId
d join e on d.id = e.tid
e join f on e.tid = f.code

inner join 和 left join 的区别

我们写update语句的时候，肯定是想要用join连表的。但是到底是使用inner join；还是left join比较好呢？

• left join：
  select a.*,b.* from a left join b on a.id = b.id , 这两个表连接，根据后面的on条件，如果b表里面的b.id不符合 a.id = b.id ，那么a表里面的所有数据列都会给展示出来。然后b表没有这种数据，所以sql里面的 b.* 会被全部填充成null

• inner join：
  select a.*,b.* from a inner join b on a.id = b.id , 这两个表连接，根据后面on条件，如果b表里面的b.id不符合 a.id = b.id ，那么a表里面的部分数据列（不符合a.id = b.id条件的）就不会展示。

根据上面的定义，left join常用于select 语句；这是为了防止a表会少一些匹配记录，为了能展示全a表，所以使用left join。

如下图所示：

索引角度理解小结果集驱动大结果集

不管是 left join 和 inner join，都要注意小结果集驱动大结果集。a表 join b表的时候，

还是看之前例子的SQL:

select a.*,b.* from a left join b on a.id = b.id

假设a表数量级是100万条，b表数量级是100条。我这样连接，就是大表驱动小表；直接看查找次数：

在用后面on条件连接两个表的时候，首先要走B+树索引进行匹配；拿a表这100w的数量级，逐条对比 -> B+树 -> 匹配到 b表的记录。假设B+树查找b表的100条要用2次查找，那么最终查找次数就是： 100万 * 2 次

如果是小表驱动大表：

select a.*,b.* from b left join a on a.id = b.id

那么就会拿b表这100条，逐条对比 -> B+树 -> 匹配到 a表的记录。假设B+树查找a表的100w条要用3次查找，那么最终查找次数就是： 100 * 3 次

从索引匹配的角度讲，小结果集驱动大结果集的效率优化了不是一点半点。我们要有意识地让小表在左边，大表在右边

但是如果你用的是inner join，MySQL内部会做优化，自动让小表在前大表在后。也就是说你怎么写，效率都是一样的。但是left join却不能自动优化，这点需要注意！

update语句常用 inner join而不是left join

举例如下SQL:

（任务目标：用f 表字段更新a表字段）

update a 
inner join b on a.id = b.id
inner join c on b.id = c.mainId
inner join d on c.id = d.tableId
inner join e on d.id = e.tid
inner join f on e.tid = f.code
set a.Demand_orgid = f.req_org_id
where xxx = xxx;

update 原则上 都得用inner join。

看上面的SQL，假设你全部都用的left join做关联，由于你最终update 的是 a的字段；假设a表在left join的过程中，因为某个点匹配不到f表，那么用f 表字段更新a表字段 这一个过程中，一旦有任意一个环节匹配不到，那么f 表的字段全都会用null填充。最终，a表匹配不到f表的数据，都会被更新成null ！

但是如果你用inner join，用f 表字段更新a表字段 这一个过程中，一旦有任意一个环节匹配不到，那么a表匹配不到 f 表的所有数据就不会显示，也就是说不会更新。

你想想，你都匹配不到数据列。你还更新啥，难道更新null吗。基于上面的原因，inner join 其实就满足需求了

况且！left join 要考虑这几张表的大小关系，谁大谁小，小结果集驱动大结果集。但是inner join 就完全不用考虑此问题，因为inner join MySQL内部会做优化，自动让小表在前大表在后。