oracle关联表查询使用索引_SQL 查询优化之 WHERE 和 LIMIT 使用索引的奥秘
点击上方SQL数据库开发，关注获取SQL视频教程
SQL专栏
SQL数据库基础知识汇总SQL数据库高级知识汇总作者：风过无痕-唐
www.cnblogs.com/tangyanbo/p/6378741.html
奇怪的慢sql
我们先来看2条sql
第一条：
select * from acct_trans_log WHERE acct_id = 1000000000009000757
order by create_time desc limit 0,10第二条：
select * from acct_trans_log WHERE acct_id = 1000000000009003061
order by create_time desc limit 0,10
第二条执行计划：
仔细观察会发现，索引只使用了idx_create_time，没有用到idx_acct_id。 这能解释第一条sql很慢，因为where查询未用到索引，那么第二条为什么这么快？ 看起来匪夷所思，其实搞清楚mysql查询的原理之后，其实很简单。 我们来看这2条sql查询，都用到了where order by limit。 当有limit存在时，查询的顺序就有可能发生变化，这时并不是从数据库中先通过where过滤再排序再limit。 因为如果这样的话，从500万数据中通过where过滤就不会是5s了。 此时的执行顺序是，先根据idx_create_time索引树，从最右侧叶子节点，反序取出n条，然后逐条去跟where条件匹配。 若匹配上，则得出一条数据，直至取满10条为止，为什么第二条sql要快，因为运气好，刚好时间倒序的前几条就全部满足了。 搞清楚原理之后，我们了解了为什么第一条慢，第二条快的原因，但是问题又来了 为什么mysql不用idx_acct_id索引，这是一个问题，因为这样的话，我们的建立的索引基本失效了，在此类sql下 查询效率将会是相当低。 因为通过acct_id过滤出来的结果集比较大，有上万条，mysql认为按时间排序如果不用索引，将会是filesort,这样会很慢，而又不能2个索引都用上 ，所以选择了idx_create_time。
为什么mysql只用一个索引 这里为什么不能2个索引都用上，可能很多人也不知道为什么，其实道理很简单，每个索引在数据库中都是一个索引树，其数据节点存储了指向实际 数据的指针，如果用一个索引来查询，其原理就是从索引树上去检索，并获得这些指针，然后去取出数据。 试想，如果你通过一个索引，得到过滤后的指针，这时，你的另一个条件索引如果再过滤一遍，将得到2组指针的集合，如果这时候取交集，未必就很快，因为如果每个集合都很大的话，取交集的时候，等于扫描2个集合，效率会很低，所以没法用2个索引。 当然有时候mysql会考虑临时建立一个联合索引，将2个索引联合起来用，但是并不是每种情况都能奏效，同样的道理，用一个索引检索出结果集之后，排序时，也无法用上另一个索引了。 实际上用索引idx_acct_id大多数情况还是要比用索引idx_create_time要快，我们举个例子：
select * from acct_trans_log force index(idx_acct_id)
WHERE acct_id = 1000000000009000757
order by create_time desc limit 0,10select * from acct_trans_log force index(idx_acct_id)
WHERE acct_id = 3095
order by create_time desc limit 0,10
那么我们有没有其它解决方案呢，这种sql是我们最常见的，如果处理不好，在大数据量的情况下，耗时以及对数据库资源的消耗都很高 ，这是我们所不能接受的，我们的唯一解决方案就是让where条件和排序字段都用上索引 解决办法就是建立联合索引：
alter table acct_trans_log add index idx_acct_id_create_time(acct_id,create_time)然后执行sql:
select * from acct_trans_log WHERE acct_id = 3095
order by create_time desc limit 0,10耗时: 0.016s
联合索引让where条件字段和排序字段都用上了索引，问题解决了！
联合索引使用的原理
但是为什么能解决这个问题呢，这时大家可能就会记住一个死理，就是联合索引可以解决where过滤和排序的问题，也不去了解其原理，这样是不对的，因为当情况发生变化，就懵逼了，
下面我们再看一个sql：
select * from acct_trans_log force index(idx_acct_id_create_time)
WHERE acct_id in(3095,1000000000009000757)
order by create_time desc limit 0,10
看执行计划，排序用到了filesort，也就是说，排序未用到索引。 那么我们还是来看看，索引排序的原理，我们先来看一个sql:
select * from acct_trans_log
ORDER BY create_time limit 0,100select * from acct_trans_log
WHERE acct_id = 3095
order by create_time desc limit 0,10select * from acct_trans_log WHERE acct_id = 30953095+time13095+time23095+time3默认是升序的，也就是说，次sql相当于
select * from acct_trans_log
WHERE acct_id = 3095
order by create_timeselect * from acct_trans_log force index(idx_acct_id_create_time)
WHERE acct_id in(3095,1000000000009000757)
order by create_time desc limit 0,10查询计划使用以及使用说明
table：显示这一行数据是关于哪张表的 type：显示使用了何种类型，从最好到最差的连接类型为const,eq_ref,ref,range,index,all possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引 key：实际使用的索引，如果为null，则没有使用索引。 key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好 ref：显示索引的哪一列被使用了，如果可能的话，是一个常数 rows：mysql认为必须检查的用来返回请求数据的行数——End——后台回复关键字：1024，获取一份精心整理的技术干货后台回复关键字：进群，带你进入高手如云的交流群。推荐阅读MySQL主从复制配置详解
神奇的 SQL，GROUP BY 真扎心，原来是这样！
为什么阿里巴巴禁止使用存储过程？
同事给我埋了个坑：INSERT INTO SELECT把生产服务器炸了
阿里规定超过3张表，禁止JOIN，为何？
这是一个能学到技术的公众号，欢迎关注
点击「
」了解SQL训练营