记得在很久以前我在公司内部做过一次MySQL优化分享里面说到一个使用延迟关联实现排序分页类型SQL的优化，这个案例在《高性能MySQL》的第二版还是第三版也有提及。

延迟关联：通过覆盖索引返回所需数据行的主键，再通过主键获取所需数据。

这里我们来看一个使用延迟关联优化排序分页SQL的案例：

123456789101112131415

      mysql> select sql_no_cache * from t_user_log where appname = '发号中心' order by logintime limit 1000000,1;+---------+-----------+--------------------------+--------------+-----------------+------------------------------------+------------+-----------+-----------+| id      | uid       | username                 | appname      | loginip         | loginlocation                      | logintime  | logintype | useragent …

MySQL的连接查询包括内连接（inner join）、外连接（left/right join，下文一律以left join代替）、交叉连接（在MySQL中等价于内连接，但是在标准SQL中是不等价的）、全连接（MySQL不支持full join，但是可以通过union构造），本文主要讲解一般我们在写SQL中最常用的：内连接以及外连接两种连接查询，通过一些案例来说明我们在使用关联查询中需要注意什么问题，要怎么做才能做到最优查询。

重点说在前面

1. MySQL对表连接至今只支持nested loop join，而不支持hash join，这个是MySQL不建议执行复杂关联查询的根源（MariaDB已经实现hash join）

   通过驱动表的结果集作为循环基础数据，然后一条一条地通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。

…

MySQL的连接查询包括内连接（inner join）、外连接（left/right join，下文一律以left join代替）、交叉连接（在MySQL中等价于内连接，但是在标准SQL中是不等价的）、全连接（MySQL不支持full join，但是可以通过union构造），本文主要讲解一般我们在写SQL中最常用的：内连接以及外连接两种连接查询，通过一些案例来说明我们在使用关联查询中需要注意什么问题，要怎么做才能做到最优查询。

重点说在前面

1. MySQL对表连接至今只支持nested loop join，而不支持hash join，这个是MySQL不建议执行复杂关联查询的根源（MariaDB已经实现hash join）

   通过驱动表的结果集作为循环基础数据，然后一条一条地通过该结果集中的数据作为过滤条件到下一个表中查询数据，然后合并结果。

…

首先我们来说下in()这种方式的查询。在《高性能MySQL》里面提及用in这种方式可以有效的替代一定的range查询，提升查询效率，因为在一条索引里面，range字段后面的部分是不生效的。使用in这种方式其实MySQL优化器是转化成了n*m种组合方式来进行查询，最终将返回值合并，有点类似union但是更高效。同时它存在这一些问题：

老版本的MySQL在IN()组合条件过多的时候会发生很多问题。查询优化可能需要花很多时间，并消耗大量内存。新版本MySQL在组合数超过一定的数量就不进行计划评估了，这可能导致MySQL不能很好的利用索引。

这里的“一定数量”在MySQL5.6.5以及以后的版本中是由eq_range_index_dive_limit这个参数控制（感谢 …

首先我们来说下in()这种方式的查询。在《高性能MySQL》里面提及用in这种方式可以有效的替代一定的range查询，提升查询效率，因为在一条索引里面，range字段后面的部分是不生效的。使用in这种方式其实MySQL优化器是转化成了n*m种组合方式来进行查询，最终将返回值合并，有点类似union但是更高效。同时它存在这一些问题：

老版本的MySQL在IN()组合条件过多的时候会发生很多问题。查询优化可能需要花很多时间，并消耗大量内存。新版本MySQL在组合数超过一定的数量就不进行计划评估了，这可能导致MySQL不能很好的利用索引。

这里的“一定数量”在MySQL5.6.5以及以后的版本中是由eq_range_index_dive_limit这个参数控制（感谢 …

昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点：

第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的；

第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在；

第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引；

第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想；

SQL:
执行时间：
mysql> select c.yh_id,
-> c.yh_dm,
-> c.yh_mc,
-> c.mm,
-> c.yh_lx,
-> a.jg_id,
-> a.jg_dm,
-> a.jg_mc,
-> a.jgxz_dm,
-> d.js_dm yh_js
-> from a, b, c
-> left join d on d.yh_id = c.yh_id
-> …

早上值班同事在旺旺群里面贴了一条非常复杂的SQL，用户从本地迁移到RDS Mysql出现严重性能下降，同样的数据和表结构下，在本地的数据库上只要不到1s的时间，但是在rds上好几分钟都没响应。

碰到这类问题需要考虑以下一些因素：

a.数据库的版本不同（不同的版本优化器策略不一样，或者异构数据库间的迁移：oracle–>mysql,sqlserver–>mysql），导致sql执行计划不同，最后导致sql执行时间不同；

b.数据库的配置不同（不同的内存配置，参数设置–query cache是否打开），导致sql执行时间不同；

c.数据库的数据量不同（系统遇到bug，生成了大量的垃圾数据），导致sql执行时间不同；

根据以上线索，用户是刚刚从线下迁移到RDS的，所以数据量和表结构是相同的；

…

下面的一段对话取自于和用户的一段旺旺聊天记录，在征得用户的同意后，放到我的blog中，希望更多的人能够看见，分享是一件快乐的事情;同时也想借此来说明一些问题，有时候试图用一条sql完成所有的业务逻辑可能会遇到麻烦，需要对复杂的sql进行一些拆分，可能会得到更好的效果，好吧，废话少说，进入正题：

RDS用户：(17:06:28):
EXPLAIN SELECT COUNT(DISTINCT mobile) AS clientcount , COUNT(aliww) AS aliwwcount , COUNT(DISTINCT email) AS emailcount FROM users_260030441 WHERE sid = 260030441
这sql怎么优化啊 表中有85W数据
Me~：(17:14:21):
优化这种sql 首先需要会explain 能够看懂explain的内容 explain的内容贴出来
RDS用户：(17:16:02):

Me~：(17:16:51):
…