精华内容
下载资源
问答
  • Using temporaryUsing filesort

    万次阅读 多人点赞 2019-06-13 23:35:26
    通过explain查看sql的执行计划时,... Using filesort,其中此次重点关注Using temporary; Using filesort。 Using temporary Using temporary表示由于排序没有走索引、使用union、子查询连接查询、使用某些视图等...

    通过explain查看sql的执行计划时,Extra字段的值往往会看到Using where; Using index; Using temporary; Using filesort,其中此次重点关注Using temporary; Using filesort

    Using temporary

    Using temporary表示由于排序没有走索引、使用union、子查询连接查询、使用某些视图等原因(详见internal-temporary-tables),因此创建了一个内部临时表。注意这里的临时表可能是内存上的临时表,也有可能是硬盘上的临时表,理所当然基于内存的临时表的时间消耗肯定要比基于硬盘的临时表的实际消耗小。

    查看sql执行时使用的是内存临时表还是硬盘临时表,需要使用如下命令:

    mysql> show global status like '%tmp%';
    +-------------------------+-------+
    | Variable_name           | Value |
    +-------------------------+-------+
    | Created_tmp_disk_tables | 0     |
    | Created_tmp_files       | 5     |
    | Created_tmp_tables      | 11    |
    +-------------------------+-------+
    3 rows in set
    

    Created_tmp_tables表示mysql创建的内部临时表的总数(包括内存临时表和硬盘临时表);Created_tmp_disk_tables表示mysql创建的硬盘临时表的总数。

    当mysql需要创建临时表时,选择内存临时表还是硬盘临时表取决于参数tmp_table_sizemax_heap_table_size,内存临时表的最大容量为tmp_table_sizemax_heap_table_size值的最小值,当所需临时表的容量大于两者的最小值时,mysql就会使用硬盘临时表存放数据。

    用户可以在mysql的配置文件里修改该两个参数的值,两者的默认值均为16M。

    tmp_table_size = 16M
    max_heap_table_size = 16M
    

    查看tmp_table_sizemax_heap_table_size值:

    mysql> show global variables like 'max_heap_table_size';
    +---------------------+----------+
    | Variable_name       | Value    |
    +---------------------+----------+
    | max_heap_table_size | 16777216 |
    +---------------------+----------+
    1 row in set
    
    mysql> show global variables like 'tmp_table_size';
    +----------------+----------+
    | Variable_name  | Value    |
    +----------------+----------+
    | tmp_table_size | 16777216 |
    +----------------+----------+
    1 row in set
    

    Using filesort

    如果问Using filesort是什么意思,大多数人应该会回答“基于硬盘的排序”或者“数据太多不适合内存,所以在硬盘上排序”。然而这些解释是错误的。

    Using filesort仅仅表示没有使用索引的排序,事实上filesort这个名字很糟糕,并不意味着在硬盘上排序,filesort与文件无关。因此消除Using filesort的方法就是让查询sql的排序走索引。

    filesort使用的算法是QuickSort,即对需要排序的记录生成元数据进行分块排序,然后再使用mergesort方法合并块。其中filesort可以使用的内存空间大小为参数sort_buffer_size的值,默认为2M。当排序记录太多sort_buffer_size不够用时,mysql会使用临时文件来存放各个分块,然后各个分块排序后再多次合并分块最终全局完成排序。

    mysql> show global variables like 'sort_buffer_size';
    +------------------+--------+
    | Variable_name    | Value  |
    +------------------+--------+
    | sort_buffer_size | 262144 |
    +------------------+--------+
    1 row in set
    

    Sort_merge_passes表示filesort执行过的文件分块合并次数的总和,如果该值比较大,建议增大sort_buffer_size的值。

    mysql> show global status like '%sort%';
    +-------------------+---------+
    | Variable_name     | Value   |
    +-------------------+---------+
    | Sort_merge_passes | 226     |
    | Sort_range        | 0       |
    | Sort_rows         | 1384911 |
    | Sort_scan         | 6       |
    +-------------------+---------+
    4 rows in set
    

    filesort排序方式

    filesort使用的排序方法有两种:

    第一种方法是对需要排序的记录生成<sort_key,rowid>的元数据进行排序,该元数据仅包含排序字段和rowid。排序完成后只有按字段排序的rowid,因此还需要通过rowid进行回表操作获取所需要的列的值,可能会导致大量的随机IO读消耗;

    第二种方法是是对需要排序的记录生成<sort_key,additional_fields>的元数据,该元数据包含排序字段和需要返回的所有列。排序完后不需要回表,但是元数据要比第一种方法长得多,需要更多的空间用于排序。

    参数max_length_for_sort_data字段用于控制filesort使用的排序方法,当所有需要排序记录的字段数量总和小于max_length_for_sort_data时使用第二种算法,否则会用第一种算法。该值的默认值为1024。

    mysql> show global variables like 'max_length_for_sort_data';
    +--------------------------+-------+
    | Variable_name            | Value |
    +--------------------------+-------+
    | max_length_for_sort_data | 1024  |
    +--------------------------+-------+
    1 row in set
    
    mysql> set global max_length_for_sort_data = 1024;
    
    展开全文
  • Using filsort文档中的解释: Mysql需要额外的一次传递,以找出如何按排序顺序检索行,通过根据联接类型浏览所有行并为所有匹配where子句的行保存排序关键字和行的指针来完成排序,然后关键字被排序,并按排序顺序...

    Using filsort文档中的解释:
    Mysql需要额外的一次传递,以找出如何按排序顺序检索行,通过根据联接类型浏览所有行并为所有匹配where子句的行保存排序关键字和行的指针来完成排序,然后关键字被排序,并按排序顺序检索行。额外的传递是指什么?

    Mysql> show create table test_filesort\G;
    *************************** 1. row ***************************
       Table: test_filesort
    Create Table: CREATE TABLE `test_filesort` (
    `a` int(11) DEFAULT NULL,
    `b` int(11) DEFAULT NULL,
    `c` int(11) DEFAULT NULL,
    KEY `a_2` (`a`)
    ) ENGINE=MyISAM DEFAULT CHARSET=latin1
    1 row in set (0.00 sec)
    ERROR:
    No query specified
    Mysql> explain select * from test_filesort where a=1 order by b;
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-----------------------------+
    | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-----------------------------+
    | 1 | SIMPLE | test_filesort | ref | a_2 | a_2 | 5 | const | 1 | Using where; Using filesort |
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-----------------------------+
    1 row in set (0.00 sec)
    Mysql> alter table test_filesort add index(a,b);
    Query OK, 6 rows affected (0.04 sec)
    Records: 6 Duplicates: 0 Warnings: 0
    Mysql> explain select * from test_filesort where a=1 order by b;
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-------------+
    | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-------------+
    | 1 | SIMPLE | test_filesort | ref | a_2,a | a | 5 | const | 1 | Using where |
    +----+-------------+---------------+------+---------------+------+---------+-------+------+-------------+
    1 row in set (0.00 sec)

    额外传递指的是多做了一次排序,很少人会把所有需要排序的字段都放到索引中,出现Using filesort不一定就会有什么性能问题。当然,我是希望尽量在应用中实现order by排序,如果放在数据库这边实现,查询次数又非常大的话,尽量考虑把字段直接冗余到索引中去,避免Mysql自身的排序机制可能会引起的性能下降。


    1.order by时可能会出现Using filesort。
    2.order by b,如果b列不在索引中,不管b值是否相同,总会出现Using filesort。
    3.并不是说所有的索引都可以避免Using filesort,hash索引是不按顺序来保存数据的。


    1.如果order by 没有利用到索引,那么将会出现fileSort,如果sort_buffer不够大,fileSort过程则需要使用临时文件,fileSort优化,主要通过调整环境来达到,如下
    2.设置参数,优化order by 时可能出现的file sort:
       将sort_buffer_size = 1M  read_rnd_buffer_size = 1M
       修改为sort_buffer_size = 16M read_rnd_buffer_size = 16M
    避免order by 过程 进行fileSort排序过程临时文件的产生。从3秒->0.7秒左右


    参考:MySQL Order By实现原理分析和Filesort优化


    3. 优化Filesort

    当无法避免排序操作时,又该如何来优化呢?很显然,应该尽可能让 MySQL 选择使用第二种单路算法来进行排序。这样可以减少大量的随机IO操作,很大幅度地提高排序工作的效率。

    1. 加大 max_length_for_sort_data 参数的设置

    在 MySQL 中,决定使用老式排序算法还是改进版排序算法是通过参数 max_length_for_ sort_data 来决定的。当所有返回字段的最大长度小于这个参数值时,MySQL 就会选择改进后的排序算法,反之,则选择老式的算法。所以,如果有充足的内存让MySQL 存放须要返回的非排序字段,就可以加大这个参数的值来让 MySQL 选择使用改进版的排序算法。

    2. 去掉不必要的返回字段

    当内存不是很充裕时,不能简单地通过强行加大上面的参数来强迫 MySQL 去使用改进版的排序算法,否则可能会造成 MySQL 不得不将数据分成很多段,然后进行排序,这样可能会得不偿失。此时就须要去掉不必要的返回字段,让返回结果长度适应 max_length_for_sort_data 参数的限制。

    3. 增大 sort_buffer_size 参数设置

    增大 sort_buffer_size 并不是为了让 MySQL选择改进版的排序算法,而是为了让MySQL尽量减少在排序过程中对须要排序的数据进行分段,因为分段会造成 MySQL 不得不使用临时表来进行交换排序。


    注:
    key:显示Mysql实际决定使用的索引
    Using index:只从索引中检索数据,不回表
    key_len:显示Mysql决定使用的键长度
    rows:显示Mysql认为它执行查询时必须检查的行数
    ref:使用哪个列或常数与key一起从表中选择行
    possible_keys:指出Mysql可以使用哪个索引在该表中找到行


    网上案例分析:

    MySQL 数据库,MyISAM 类型的表 table_item,有 5、6 个字段,主键是 id。
    user_id 和 item_id 两个字段都是单独的 INDEX 类型的索引。
    问题是如何发现的?
    在自己的开发环境下,打开一个简单的页面都要好长时间,不知道问题出在哪里,只发现硬盘灯闪个不停。
    观察 Windows 的任务管理器,看到 mysqld-nt.exe 这个进程的 "I/O 读取字节" 高达十几 G!!!
    再次测试,发现每次刷新页面,这个进程要读取几十 M 的数据。
    奇了怪了,查看 SQL 语句,还有表结构,字段都建了索引了呀。
    后来 EXPLAIN 了一下,看到结果是 Using where; Using filesort。
    explain SELECT * FROM table_item WHERE user_id = 2 ORDER BY item_id LIMIT 0, 5
    翻了 MySQL 手册,仔细看下 filesort 的说明,知道了 Using filesort 是一种速度很慢的外部排序。
    不过我不理解为什么会使用 filesort 排序,WHERE 和 ORDER BY 用到的字段都是有索引的呀。
    赶紧 Google之,得到的启示就是索引定义不当导致MySQL 没有用到索引。
    需要了解MySQL 的特性:
    1.一条 SQL 语句只能使用 1 个索引 (5.0-)[5.0+MYSQ会分析是否做index megre],MySQL 根据表的状态,选择一个它认为最好的索引用于优化查询【use index 指定索引,纠正MYSQL错误判断
    2.联合索引,只能按从左到右的顺序依次使用,包括了group order
    3.从上边可以看到结合索引,也可以叫多列索引,形如 key ('B1','B2','B3' ,'B4')等的,排序的思路通常为,先按照B1来排序,B1相同,然后按照B2排序,以此类推,这样对于(B1),(B1,B2), (B1,B2,B3)的索引都是有效的,可是对于(B2,B3)这样的索引就无效了。
    根据这个特性就可以解决问题:

    user_id 和 item_id 是 2 个索引,我的语句中,MySQL 选择了 user_id,那么 item_id 的索引没有起到任何用处,所以,当我要排序的时候,由于user_id索引取得的记录数较多,内存中的排序 buffer 满了,只能 Using filesort 进行外部排序,因此每次查询要从磁盘读取几十 M 的数据,太慢了。
    修改表结构,删除 user_id 和 item_id 的 INDEX 索引,建立一个名为 user_item 的联合 UNIQUE 索引,顺序是先 user_id 后 item_id,再 EXPLAIN,这回只有 Using where 了。
    再刷新页面,观察任务管理器,mysqld-nt.exe 只读取了 2K 的数据,页面咔的一下就出来了……


    展开全文
  • Using Index Condition  在MySQL 5.6版本后加入的新特性(Index Condition Pushdown);会先条件过滤索引,过滤完索引后找到所有符合索引条件的数据行,随后用 WHERE 子句中的其他条件去过滤这些数据行; 够用...

      最近因为项目很赶,很久没写博客了,今天算是已经把项目进度超前完成了,写一个今天解决的SQL优化问题。

      这次优化花了半小时,但很值得,之前作为一个单纯后端,很少关注SQL效率,但是自从上个项目当上临时DBA后,或多或少的都会关注自己书写的SQL执行计划。

       原始第一映像写出的脚本: 

       EXPLAIN
    SELECT
        service_id,service_name,count(1)
    FROM
        order_orders t1,
        order_user_coupon t2
    WHERE
        t1.coupon_id = t2.coupon_id
    AND t1.merchant_id = '1'
    AND (
        t1.update_time BETWEEN str_to_date(
            '2019-01-01 00:00:00',
            '%Y-%m-%d %H:%i:%s'
        )
        AND str_to_date(
            '2019-03-06 00:00:00',
            '%Y-%m-%d %H:%i:%s'
        )
    )
    group by service_id;

    执行计划如下:

    两张表各种加索引,没用,后来仔细分析了一下,之所以产生临时表,是因为整个查询过程,你首先要通过关联条件查询出一个结果集,然后再根据这个结果集进行分组排序,自然就会有临时表和文件排序。

     

    第二次优化脚本如下:

    EXPLAIN SELECT
        t1.service_id,
        t1.service_name,
        count(1)
    FROM
        order_user_coupon t1
    WHERE
        t1.coupon_id in(
            SELECT
                coupon_id
            FROM
                order_orders t2
            WHERE
         t2.merchant_id = '1'
            AND t2.update_time BETWEEN str_to_date(
                '2019-01-01 00:00:00',
                '%Y-%m-%d %H:%i:%s'
            )
            AND str_to_date(
                '2019-03-06 00:00:00',
                '%Y-%m-%d %H:%i:%s'
            )
        )
    GROUP BY
        t1.service_id;

    本想着,避免了关联查询,使用t1表的结果集做分组,应该能避免临时表及文件排序,结果没想到in中的查询使用了,好吧,废弃。

     

    第三次优化如下:

    EXPLAIN SELECT
        t1.service_id,
        t1.service_name,
        count(1)
    FROM
        order_user_coupon t1
    WHERE
        EXISTS (
            SELECT
                coupon_id
            FROM
                order_orders t2
            WHERE
                t1.coupon_id = t2.coupon_id
            AND t2.merchant_id = '1'
            AND t2.update_time BETWEEN str_to_date(
                '2019-01-01 00:00:00',
                '%Y-%m-%d %H:%i:%s'
            )
            AND str_to_date(
                '2019-03-06 00:00:00',
                '%Y-%m-%d %H:%i:%s'
            )
        )
    GROUP BY
        t1.service_id;

    思路:以条件筛选出t2表中数据,以少量数据作为驱动,查询t1表关联数据,之后基于t1表的结果集进行group by操作。

    完美解决!

     

    最后优化索引:

    1、 group by 后的字段一定是要添加索引的,否则还是 临时表进行排序;

    2、 这里merchant_id基本能完成大部分数据筛选了,所以添加merchant_id的索引,而不再添加coupon_id索引。

    最终结果如下:

    Using Index Condition

         在MySQL 5.6版本后加入的新特性(Index Condition Pushdown);会先条件过滤索引,过滤完索引后找到所有符合索引条件的数据行,随后用 WHERE 子句中的其他条件去过滤这些数据行;

    够用了,完美!

     

    展开全文
  • 先看一段sql: SELECT * FROM rank_user AS rankUser LEFT JOIN rank_user_level AS userLevel ON rankUser.id = userLevel.user_id LEFT JOIN rank_product AS product ON userLevel.new_level = prod...

    先看一段sql:

    SELECT  
        *  
    FROM  
        rank_user AS rankUser  
    LEFT JOIN rank_user_level AS userLevel ON rankUser.id = userLevel.user_id  
    LEFT JOIN rank_product AS product ON userLevel.new_level = product.level_id  
    LEFT JOIN rank_product_fee AS fee ON userLevel.fee_id = fee.fee_id  
    LEFT JOIN rank_user_login_stat AS userLoginInfo ON rankUser.id = userLoginInfo.user_id  
    ORDER BY  
         rankUser.create_time DESC  
    LIMIT 10 OFFSET 0</span>  
    

    介绍一下这段sql的表的构成:一张主表:rank_user;两张跟rank_user直接关联(多张表通过同一字段最好是主键进行关联)的表:rank_user_level ,rank_user_login_stat ;两张跟rank_user非直接关联的表:rank_product ,rank_product_fee 。这段sql看似简单,但是执行时间却很长,我们来看一下执行计划:

    在这里插入图片描述
    执行时间1.45s,可以看到,这段不仅仅扫描全表,而且使用了临时表,进行了文件排序。

    为了找到原因,我们把排序去掉看一下:

    SELECT  
        *  
    FROM  
        rank_user AS rankUser  
    LEFT JOIN rank_user_level AS userLevel ON rankUser.id = userLevel.user_id  
    LEFT JOIN rank_product AS product ON userLevel.new_level = product.level_id  
    LEFT JOIN rank_product_fee AS fee ON userLevel.fee_id = fee.fee_id  
    LEFT JOIN rank_user_login_stat AS userLoginInfo ON rankUser.id = userLoginInfo.user_id  
    -- ORDER BY  
        -- rankUser.create_time DESC  
    LIMIT 10 OFFSET 0  
    

    在这里插入图片描述
    执行时间0.015s,扫描行数67452,果然是排序惹的祸。但是仅仅是排序惹的祸吗?别忘了这里有两张非直接关联的表,这样的查询,如果有查询条件或者排序分组的时候往往都需要创建临时表(这个没有办法,想想也知道)。为了验证这个观点,我们把两张非直接关联的表去掉看一下:

    SELECT  
        *  
    FROM  
        rank_user AS rankUser  
    LEFT JOIN rank_user_level AS userLevel ON rankUser.id = userLevel.user_id  
    -- LEFT JOIN rank_product AS product ON userLevel.new_level = product.level_id  
    -- LEFT JOIN rank_product_fee AS fee ON userLevel.fee_id = fee.fee_id  
    LEFT JOIN rank_user_login_stat AS userLoginInfo ON rankUser.id = userLoginInfo.user_id  
    ORDER BY  
        rankUser.create_time DESC  
    LIMIT 10 OFFSET 0  
    

    在这里插入图片描述
    执行时间0.003s,扫描行数10,屌爆了有木有,mysql多表直接关联在没有其他筛选条件的情况下,查询速度大大提升,而且排序可以使用create_time这个索引,直接取到前十条。

    到了这里,我想大家应该已经明白第一条sql查询时间很长的原因了:多表非直接关联的前提下还要排序。mysql查询往往最需要优化的地方就是临时表和文件排序了。这里总结一下教训:

    1.mysql查询存在直接关联和非直接关联的问题,这两种查询效率差别很大;

    2.mysql排序尽量使用索引;

    3.mysql多表关联left join其他表的时候,如果以其他表的字段作为查询条件都会产生临时表;

    4.mysql在非直接关联的基础上进行排序会很慢,需要进行优化;

    知道了问题,我们就好优化了,这里我给出了两种方案:

    第一种(子查询,适合子查询部分不作为查询条件):

    SELECT  
                rankUser.id, rankUser.qq, rankUser.phone, rankUser.regip, rankUser.channel, rankUser.create_time, rankUser.qudao_key, rankUser.qq_openid, rankUser.wechat_openid,  
                userLevel.recommend_count,userLevel.end_time,userLevel.new_level,userLevel.`level`,userLevel.new_recommend_count,userLevel.`is_limited`,  
                (case when userLevel.new_level > 1 then 1 else 0 end) is_official_user,  
                (select product_name from rank_product where level_id = userLevel.new_level) product_name,  
                (select period from rank_product_fee where fee_id = userLevel.fee_id) period,  
                userLoginInfo.last_login, userLoginInfo.login_count, userLoginInfo.login_seconds  
            FROM rank_user AS rankUser  
            LEFT JOIN rank_user_level as userLevel on userLevel.user_id=rankUser.id  
            LEFT JOIN rank_user_login_stat as userLoginInfo ON rankUser.id = userLoginInfo.user_id  
    ORDER BY  
        rankUser.create_time DESC  
    LIMIT 10 OFFSET 0  
    

    在这里插入图片描述
    第二种(非直接关联转变成直接关联,这个要根据业务来定,我这里rank_product和rank_product_fee两张表只是为了查询rank_user_level表中的产品和产品费用信息,而rank_user_level是一张直接关联的表,故这里可以先将这三张表进行合并,然后再和rank_user表进行联合查询):

    SELECT  
        *  
    FROM  
        rank_user AS rankUser  
    LEFT JOIN (  
            select   
            l.*,p.product_name,f.period   
            from   
            rank_user_level l,rank_product p,rank_product_fee f  
            where   
            l.new_level = p.level_id   
            and l.fee_id = f.fee_id  
    ) AS userLevel ON rankUser.id = userLevel.user_id  
    LEFT JOIN rank_user_login_stat AS userLoginInfo ON rankUser.id = userLoginInfo.user_id  
    ORDER BY  
        rankUser.create_time DESC  
    LIMIT 10 OFFSET 0  
    

    在这里插入图片描述

    原链接:https://www.cnblogs.com/jpfss/p/9156422.html

    展开全文
  • 所以查询执行计划中出现“Using temporary”字样就表示MySQL采用了常规的处理方式)和在文件内进行了排序,才返回出来,可知这不是最优路线 公司数据库的原因不敢随便建立索引,对于Using temporary; Using ...
  • 因此主键选用有序的顺序ID而不是无序的UUID mysql using temporary Temporary tables can be created under conditions such as these: If there is an ORDER BY clause and a different GROUP BY clause, or if the...
  • 多表关联时,在order by中使用了非驱动表字段进行排序,会出现Using temporary; Using filesort,此时需要优化。 mysql会自动将数据量较小的表设置为驱动表,但是我们排序的字段又不是该表的字段,使用left join,...
  • 解释一: These are the following conditions under which temporary tables are created. UNION queries use temporary tables...Some views require temporary tables, such those evaluated using the TEMPTABLE...
  • 大概时间为5s左右,于是乎对改SQL场景进行EXPLAIN 分析,发现一个在执行过程中出现对“Using temporary; Using filesort ”。即在执行过程中产生了临时表来存储结果,并在排序时根据连接类型以及存储排序键值和匹配...
  • 首先, group by后面是两个字段时, explain的extra不会出现using temporary <p><img alt="" height="490" src="https://img-ask.csdnimg.cn/upload/1618914519014.png" width="1276" /></p> 然后当group by后的字段...
  • 下面的mysql代码因为order by的原因,出现了Using temporaryUsing filesort,优化前代码如下 SELECT DISTINCT ( tm.task_no ) task_no, tm.start_time, tm.end_time, tm.task_handler job_no, cb.claim_company_code...
  • 在正式环境中,两张表内联查询的计划有Using temporary; Using filesort,这是导致效率下降的原因之一。 修改SQL语句,将order by 字段 作为查询条件之下,优化如下: select a.id ,a.goods_id,a.goods_name,a....
  • -- 查看执行计划,虽然没有了DERIVED、derived2,但是看到还有Using temporary; Using filesort存在 +----+-------------+-------+--------+-------------------------------+-------------------------------+----...
  • 针对limit优化,以及讨论using filesort、using temporary和索引失效的问题 表结构 CREATE TABLE `a` ( `id` INT(11) NOT NULL AUTO_INCREMENT, `code` CHAR(36) DEFAULT NULL, `name` CHAR(20) DEFAULT NULL,...
  • Mysql-explain之Using temporaryUsing filesort解决方案
  • mysql-explain之Using temporary

    千次阅读 2020-10-28 10:37:53
    今天同事问到我一个问题,说某个带有join的查询语句创建视图后,查询视图时带有order by字段时,某些字段会很快,某些会稍微慢一些。 drop view if exists test1; create view test1 as select a.*,b.b_info_...
  • using filesort 用Explain分析SQL语句的时候,经常发现有的语句在Extra列会出现Using filesort,mysql官方文档对他的描述也很奇怪,不好理解 概念:mysql会对数据使用一种外部索引排序,而不是基于表内部索引顺序来...
  • 执行计划,没有出现Using temporary; Using filesort 5、总结 如果将PRODUCTONESORTVMID放在前面,PUBLISH_DATE 在后面 则没有效果。所以建立联合索引时,排序的要在前面。原因大概是: 1、去掉连接查询,...
  • MySQL调优 —— Using temporary

    万次阅读 2015-08-04 02:10:25
    出乎意料, 竟然会有Using temporary, order by只用到了一张表, 正常情况下不会出现借助辅助表再进行排序的情况(这种情况是多个表都涉及到排序字段才会引起的), 正常情况应该是只在排序有关系的表排序后然后就...
  • 使用EXPLIAN字段可以对sql语句进行分析,当extra有Using temporary; Using filesort等时表示需要进行优化,意思分别是用了临时表和一种sql的排序。 eg1: select * from a inner join b where a.id=b.aid order by ...
  • order by产生的 Using temporary的优化

    千次阅读 2019-03-25 16:34:59
    因为t_athlete_score 是主表,左连接到t_comp_section ,现在排序使用的第二个表的数据,所以产生了Using temporary,具体的产生原因,在 http://mysql.taobao.org/monthly/2015/03/04/ 上讲的很清楚了,所以...
  • 在使用explain优化sql的时候,有Using temporary; Using filesort这两种是需要特别注意的: Using temporary:在MySQL执行查询的过程中自动产生临时表(Creating tmp table) Using filesort:是指查询完成之前...
  • mysql使用roll up后sql出现Using temporary; Using filesort,怎么优化啊
  • 本系列文章目录 展开/收起 Mysql索引篇(一) 索引的数据... Mysql索引篇(四) 覆盖索引(Using index)、文件排序(Using filesort)和临时表(Using temporary) ...
  • temporary ; Using filesort | |  1 | SIMPLE     | B     | eq_ref | PRIMARY     | PRIMARY | 4     | joomla_test . A . catid     ...
  • 看到type类型基本都走了索引,而且extra列内还有using temporaryusing filesort,他们用到了临时表和在文件内进行了排序,才返回出来,这肯定不是按照我们原先设计的最优路线来走的,而且相关的索引路线都没走上,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 68,766
精华内容 27,506
关键字:

temporaryusing