『壹』 有关多表Left join的优化
1、因为T1表式主表，所以
【select COUNT(DISTINCT T1.A1) from T1】和你求出的
【COUNT(DISTINCT T1.A1)】值是一样的。
2、而由于T2等是从表并且你使用了【COUNT(DISTINCT T2.B1)】因此null值会被排除掉，实际上和下面的语句求出的值是一样的
select COUNT(DISTINCT T2.B1) from T1 inner join T2 on T1.A1 = T2.A1;
3、从上面的分析可以看出你使用【left join】的目的只有一个就是得到【T1】表全部数据的【COUNT(DISTINCT T1.A1)】，所以试试改成下面的sql是否性能能够快些
select cnt1+cnt2+cnt3 from(
(select COUNT(DISTINCT T1.A1) cnt1 from T1 GROUP BY T1.A2, T1.A3)t1,
(select COUNT(DISTINCT T2.B1) cnt2 from T1 inner join T2 on T1.A1 = T2.A1 GROUP BY T1.A2, T1.A3)t2,
(select COUNT(DISTINCT T3.C1) cnt3 from T1 inner join T3 on T1.A1 = T3.A1 inner join T4 on T3.C1 = T4.C1 GROUP BY T1.A2, T1.A3)t3;
---
以上，希望对你有所帮助。
『贰』 mysql两个left join查询如何优化
select a.*,jjr_project_id,project_typeid,project_type,project_title,project_manageid,project_endtime from zhaop_jobfair_person_wei a
left join jjr_project b on a.jobfair_id=b.project_typeid ----这里可以直接查询对应表的单个字段而不是全部字段
left join zhaop_jobfair_wei c on a.jobfair_wei_id=c.id
where 1=1 and is_hidden=10 and sa_user_id='1'
left join外连接涉及的表都是不一样表，sql优化之能通过查询相应的目标字段优化，你这里所有的字段都会被查询，效率肯定会低一点，底层优化那就建立索引
『叁』 sql一个left join的语句优化，因为描述不完所以在问题补充里面说明
你的这个查询SQL语句中有使用like作为条件，而且有2个like(c.phone like '1%'; c.main_proct like '1%'), 而like肯定会降低查询效率的。ph_cotent表中phone, main_proct上有建索引吗? 这些值的重复性高不高?
另外，条件中有使用了or条件(b.id is null or b.parent_id != 1)，这也会降低效率.。可以考虑使用union将or条件分开成两个查询。
『肆』 多个表left join 用 order by fetch first rows only 放在join之前优化，怎么写
多表联合查询语句：SELECT * FROM table LEFT JOIN ...ON.... WHERE ...ORDER BY ....LIMIT ....
拿laizijiding的例子说明问题：三个表 板块表（block）、帖子表（post）、会员表（user）
如果查询 帖子列表中 帖子 是属于哪个板块和添加帖子的会员信息，sql语句如下：
SELECT * FROM post LEFT JOIN block ON....LEFT JOIN user ON....WHERE ...ORDER BY ....LIMIT ....(1)
这样写是没有问题的，也可以这样写：
SELECT * FROM post LEFT JOIN user ON....LEFT JOIN block ON....WHERE ...ORDER BY ....LIMIT ....(2)
上面两个到底哪个效率高呢，应该是（1）效率较高，关于连接条件的优化在顺序上有个原则：数剧量少的条件尽量写在前面。一个论坛当中板块的数量要比用户的数量小的多了。
『伍』 left join 后，左表怎样合并或者去掉重复记录
在 MySQL 查询中，可能会包含重复值。这并不成问题，不过，有时您也许希望仅仅列出不同（distinct）的值。 关键词 DISTINCT 用于返回唯一不同的值，就是去重啦。用法也很简单： SELECT DISTINCT * FROM tableName DISTINCT 这个关键字来过滤掉多余的重复记录只保留一条。 另外，如果要对某个字段去重，可以试下： SELECT *, COUNT(DISTINCT nowamagic) FROM table GROUP BY nowamagic 这个用法，MySQL的版本不能太低。 在编写查询之前，我们甚至应该对过滤条件进行排序，真正高效的条件（可能有多个，涉到同的表）是查询的主要驱动力，低效条件只起辅助作用。那么定义高效过滤条件的准则是什呢？首先，要看过滤条件能否尽快减少必须处理的数据量。所以，我们必须倍加关注条件的写方式。 假设有四个表： customers 、 orders 、 orderdetail 、 articles ，现在假设 SQL 要处理的问题是：找出最近六个月内居住在 Gotham 市、订购了蝙蝠车的所有客户。当然，编写这个查询有多种方法， ANSI SQL 的推崇者可能写出下列语句： select distinct c.custname from customers c join orders o on o.custid = c.custid join orderdetail od on od.ordid = o.ordid join articles a on a.artid = od.artid where c.city = 'GOTHAM' and a.artname = 'BATMOBILE' and o.ordered >= somefunc 其中， somefunc 是个函数，返回距今六个月前的具体日期。注意上面用了 distinct ，因为考虑到某个客户可以是大买家，最近订购了好几台蝙蝠车。 暂不考虑优化器将如何改写此查询，我们先看一下这段代码的含义。首先，来自 customers 表的数据应只保留城市名为 Gotham 的记录。接着，搜索 orders 表，这意味着 custid 字段最好有索引，否则只有通过排序、合并或扫描 orders 表建立一个哈希表才能保证查询速度。对 orders 表 ，还要针对订单日期进行过滤：如果优化器比较聪明，它会在连接（ join ）前先过滤掉一些数据，从而减少后面要处理的数据量；不太聪明的优化器则可能会先做连接，再作过滤，这时在连接中指定过滤条件利于提高性能，例如： join orders o on o.custid = c.custid and a.ordered >= somefunc 注意，如果是： left outer join orders o on o.custid = c.custid and a.ordered >= somefunc 此处关于left表的筛选条件将失效，因为是左外连接，左表的所有列都将出现在这次连接结果集中）。 即使过滤条件与连接（ join ）无关，优化器也会受到过滤条件的影响。例如，若 orderdetail 的主键为（ ordid, artid ），即 ordid 为索引的第一个属性，那么我们可以利用索引找到与订单相关的记录。但如果主键是（ artid, ordid ）就太不幸了（注意，就关系理论而言 ，无论哪个版本都是完全一样），此时的访问效率比（ ordid, artid ）作为索引时要差，甚至一些数据库产品无法使用该索引（注 3 ），唯一的希望就是在ordid 上加独立索引了。 连接了表 orderdetail 和 orders 之后，来看 articles 表，这不会有问题，因为表 order 包括 artid 字段。最后，检查 articles 中的值是否为 Batmobile 。查询就这样结束了，因为用了 distinct ，通过层层筛选的客户名还必须要排序，以剔除重复项目。 避免在最高层使用 distinct 应该是一条基本规则 。原因在于，即使我们遗漏了连接的某个条件， distinct 也会使查询 " 看似正确 " 地执行 —— 无可否认，发现重复数据容易，发现数据不准确很难，所以避免在最高层使用 distinct 应该是一条基本规则。 发现结果不正确更难，例如，如果恰巧有多位客户都叫 " Wayne " ， distinct 不但会剔除由同个客户的多张订单产生的重复项目，也会剔除由名字相同的不同客户产生的重复项目。事实上，应该同时返回具唯一性的客户 ID 和客户名，以保证得到蝙蝠车买家的完整清单。 要摆脱 distinct ，可考虑以下思路：客户在 Gohtam 市，而且满足存在性测试，即在最近六个月订购过蝙蝠车。注意，多数（但非全部） SQL 方言支持以下语法： select c.custname from customers c where c.city = 'GOTHAM' and exists (select null from orders o, orderdetail od, articles a where a.artname = 'BATMOBILE' and a.artid = od.artid and od.ordid = o.ordid and o.custid = c.custid and o.ordered >= somefunc ) 上例的存在性测试，同一个名字可能出现多次，但每个客户只出现一次，不管他有多少订单。有人认为我对 ANSI SQL 语法的挑剔有点苛刻（指 " 蝙蝠车买主 " 的例子），因为上面代码中customers 表的地位并没有降低。其实，关键区别在于，新查询中 customers 表是查询结果的唯一来源（嵌套的子查询会负责找出客户子集），而先前的查询却用了 join 。 这个嵌套的子查询与外层的 select 关系十分密切。如代码第 11 行所示（粗体部分），子查询参照了外层查询的当前记录，因此，内层子查询就是所谓的关联子查询（ correlated subquery ）。 此类子查询有个弱点，它无法在确定当前客户之前执行。如果优化器不改写此查询，就必须先找出每个客户，然后逐一检查是否满足存在性测试，当来自 Gotham 市的客户非常少时执行效率倒是很高，否则情况会很糟（此时，优秀的优化器应尝试其他执行查询的方式）。 select custname from customers where city = 'GOTHAM' and custid in (select o.custid from orders o, orderdetail od, articles a where a.artname = 'BATMOBILE' and a.artid = od.artid and od.ordid = o.ordid and o.ordered >= somefunc) 在这个例子中，内层查询不再依赖外层查询，它已变成了非关联子查询（ uncorrelated subquery ），只须执行一次。很显然，这段代码采用了原有的执行流程。在本节的前一个例子 中 ，必须先搜寻符合地点条件的客户（如均来自 GOTHAM ），接着依次检查各个订单。而现在，订购了蝙蝠车的客户，可以通过内层查询获得。 不过，如果更仔细地分析一下，前后两个版本的代码还有些更微妙的差异。含关联子查询的代码中，至关重要的是 orders 表中的 custid 字段要有索引，而这对另一段代码并不重要，因为这时要用到的索引（如果有的话）是表 customers 的主键索引。 你或许注意到，新版的查询中执行了隐式的 distinct 。的确，由于连接操作，子查询可能会返回有关一个客户的多条记录。但重复项目不会有影响，因为 in 条件只检查该项目是否出现在子查询返回的列表中，且 in 不在乎某值在列表中出现了一次还是一百次。但为了一致性，作为整体，应该对子查询和主查询应用相同的规则，也就是在子查询中也加入存在性测试： select custname from customers where city = 'GOTHAM' and custid in (select o.custid from orders o where o.ordered >= somefunc and exists (select null from orderdetail od, articles a where a.artname = 'BATMOBILE' and a.artid = od.artid and od.ordid = o.ordid)) 或者 select custname from customers where city = 'GOTHAM' and custid in (select custid from orders where ordered >= somefunc and ordid in (select od.ordid from orderdetail od, articles a where a.artname = 'BATMOBILE' and a.artid = od.artid) 尽管嵌套变得更深、也更难懂了，但子查询内应选择 exists 还是 in 的选择规则相同：此选择取决于日期与商品条件的有效性。除非过去六个月的生意非常清淡，否则商品名称应为最有效的过滤条件，因此子查询中用 in 比 exists 好，这是因为，先找出所有蝙蝠车的订单、再检查销售是否发生在最近六个月，比反过来操作要快。如果表 orderdetail 的 artid 字段有索引，这个方法会更快，否则，这个聪明巧妙的举措就会黯然失色。 每当对大量记录做存在性检查时，选择 in 还是 exists 须斟酌。 利于多数 SQL 方言，非关联子查询可以被改写成 from 子句中的内嵌视图。然而，一定要记住的是， in 会隐式地剔除重复项目，当子查询改写为 from 子句中的内嵌视图时，必须要显式地消除重复项目。例如： select custname from customers where city = 'GOTHAM' and custid in (select o.custid from orders o, (select distinct od.ordid from orderdetail od, articles a where a.artname = 'BATMOBILE' and a.artid = od.artid) x where o.ordered >= somefunc and x.ordid = o.ordid) 总结：保证 SQL 语句返回正确结果，只是建立最佳 SQL 语句的第一步。
『陆』 Mysql left join 查询慢如何优化
我没有看出来你和message表关联的目的是什么，我看你的查询结果中也没有用到message表中的字段。不关联message表和关联message表，对你的结果有什么影响？
『柒』 sql 优化 left join 由于数据量过大查询很慢
创建存储过程，将第一次left join关联查询出来的数据存储到临时表，再次进行关联查询试试。
若依然很慢，之后可以对作出的两次单纯的表关联查询进行检查，检查单条SQL语句的查询速度，找到慢的问题，再去优化。
『捌』 大量的left join 怎么优化
在各个表的id和time属性上创建索引，而且把其中除了第一次left join中的 b.time=a.time外，其余的 b.time=a.time去掉，并先对b表执行 b.time='2013-10-1'的查询。
如果各表都需要判断时间的话，那么请先在各表上执行基于时间的选择操作，在参加左外连接。因此，时间字段上的索引很重要。
『玖』 大神们帮忙优化一下我的SQL，主要是OR问题，我想用union 来替代，不过left join 这种怎么用啊
left join
(
select content_id from ph_search where b.id is null
union
select content_id from ph_search where b.parent_id != 1
) b
肯定是先把表过滤了再去left jion，这样一来结果集就少了，关联也快了一点
『拾』 left jion 优化
1：尽量减少left join之后的数据量，用子查询来减少它的数量
2：尽可能将其改为innerjoin，这样可以减少一些不必要的数据