Mysql之EXPLAIN显示using filesort介绍
程序员文章站
2023-12-21 10:45:28
语法格式如下 explain tbl_name 或者: explain select select_options explain 语句可以被当作 describe 的同义...
语法格式如下
explain tbl_name
或者:
explain select select_options
explain 语句可以被当作 describe 的同义词来用，也可以用来获取一个mysql要执行的 select 语句的相关信息。
explain tbl_name 语法和 describe tbl_name 或 show columns from tbl_name 一样。
当在一个 select 语句前使用关键字 explain 时，mysql会解释了即将如何运行该 select 语句，它显示了表如何连接、连接的顺序等信息。
以下信息为引用:
在explain我们所使用的sql的时候，经常会遇到using filesort这种情况，原以为是由于有相同列值的原因引起，结果昨天看到公司的一个sql，跟同事讨论了下加上自己又做了一些测试，突然发现自己原来的想法是错误的。
首先，只有在order by 数据列的时候才可能会出现using filesort，而且如果你不对进行order by的这一列设置索引的话，无论列值是否有相同的都会出现using filesort。因此，只要用到order by 的这一列都应该为其建立一个索引。
其次，在这次测试中，使用了一个稍微有点复杂的例子来说明这个问题，下面详细用这个例子说一下：
select * from db.tb where id=2222 and fid in (9,8,3,13,38,40) order by inverse_date limit 0, 5
里面建立的索引为一个三列的多列索引：idx（id,fid ,inverse_date） 。inverse_date这个是时间的反向索引。
对于这个sql我当时最开始认为应该是个优化好的状态，应该没有什么纰漏了，结果一explain才发现竟然出现了：using where; using filesort。
为什么呢，后来经过分析才得知，原来在多列索引在建立的时候是以b-树结构建立的，因此建立索引的时候是先建立id的按顺序排的索引，在相同id的情况下建立fid按 顺序排的索引，最后在fid 相同的情况下建立按inverse_date顺序排的索引，如果列数更多以此类推。有了这个理论依据我们可以看出在这个sql使用这个idx索引的时候只是用在了order by之前，order by inverse_date 实际上是using filesort出来的。。汗死了。。因此如果我们要在优化一下这个sql就应该为它建立另一个索引idx（id,inverse_date），这样就消除了using filesort速度也会快很多。问题终于解决了。
explain tbl_name
或者:
explain select select_options
explain 语句可以被当作 describe 的同义词来用，也可以用来获取一个mysql要执行的 select 语句的相关信息。
explain tbl_name 语法和 describe tbl_name 或 show columns from tbl_name 一样。
当在一个 select 语句前使用关键字 explain 时，mysql会解释了即将如何运行该 select 语句，它显示了表如何连接、连接的顺序等信息。
以下信息为引用:
在explain我们所使用的sql的时候，经常会遇到using filesort这种情况，原以为是由于有相同列值的原因引起，结果昨天看到公司的一个sql，跟同事讨论了下加上自己又做了一些测试，突然发现自己原来的想法是错误的。
首先，只有在order by 数据列的时候才可能会出现using filesort，而且如果你不对进行order by的这一列设置索引的话，无论列值是否有相同的都会出现using filesort。因此，只要用到order by 的这一列都应该为其建立一个索引。
其次，在这次测试中，使用了一个稍微有点复杂的例子来说明这个问题，下面详细用这个例子说一下：
select * from db.tb where id=2222 and fid in (9,8,3,13,38,40) order by inverse_date limit 0, 5
里面建立的索引为一个三列的多列索引：idx（id,fid ,inverse_date） 。inverse_date这个是时间的反向索引。
对于这个sql我当时最开始认为应该是个优化好的状态，应该没有什么纰漏了，结果一explain才发现竟然出现了：using where; using filesort。
为什么呢，后来经过分析才得知，原来在多列索引在建立的时候是以b-树结构建立的，因此建立索引的时候是先建立id的按顺序排的索引，在相同id的情况下建立fid按 顺序排的索引，最后在fid 相同的情况下建立按inverse_date顺序排的索引，如果列数更多以此类推。有了这个理论依据我们可以看出在这个sql使用这个idx索引的时候只是用在了order by之前，order by inverse_date 实际上是using filesort出来的。。汗死了。。因此如果我们要在优化一下这个sql就应该为它建立另一个索引idx（id,inverse_date），这样就消除了using filesort速度也会快很多。问题终于解决了。