mysql using filesort Using temporary

using filesort

一般人的回答是: “当行数据太大,导致内存无法容下这些数据产生的临时表时,他们就会被放入磁盘中排序。”  很不幸,这个答案是错的 ,临时表在太大的时候确实会到磁盘离去,但是EXPLAIN不会显示这些。

The truth is, filesort is badly named. Anytime a sort can’t be performed from an index, it’s a filesort. It has nothing to do with files. Filesort should be called “sort.” It is quicksort at heart.

那么事实是, filesort 这个名字取得太搓逼了。 filesort的意思是只要一个排序无法使用索引来排序,就叫filesort。他和file没半毛钱关系。filesort应该叫做sort。(笔者补充一下:意思是说如果无法用已有index来排序,那么就需要数据库服务器额外的进行数据排序,这样其实是会增加性能开销的。)

另外不光order by会出现filesort  group by没有使用索引一样会出现

检查sort状态

show session status like ‘%sort%‘;

sort_merge_passes  由于sort buffer不够大,不得不将需要排序的数据进行分段,然后再通过sort merge的算法完成整个过程的merge总次数,一般整个参数用来参考sort buffer size 是否足够。

sort range session/global级别(单位:次) 通过range scan完成的排序总次数。

sort rows   session/global 级别(单位:row) 排序的总行数。

sort scan   通过扫描表完成的排序总次数。

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

1. 合理设置索引 让排序字段使用上索引排序

2. 加大 max_length_for_sort_data 参数的设置

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

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

4. 增大 sort_buffer_size 参数设置

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

Using temporary

内部临时表产生的时机有以下几种:

  • 使用 ORDER BY 子句和一个不一样的 GROUP BY 子句(经过笔者实验,应该是GROUP BY一个无索引列,就会产生临时表),或者 ORDER BY 或 GROUP BY 的列不是来自JOIN语句序列的第一个表,就会产生临时表(经笔者实验,应该是使用JOIN时, GROUP BY 任何列都会产生临时表)
  • DISTINCT 和 ORDER BY 一起使用时可能需要临时表(笔者实验是只要用了DISTINCT(非索引列),都会产生临时表)
  • 用了 SQL_SMALL_RESULT, mysql就会用内存临时表。定义:SQL_BIG_RESULT or SQL_SMALL_RESULT can be used with GROUP BY or DISTINCT to tell the optimizer that the result set has many rows or is small, respectively. For SQL_BIG_RESULT, MySQL

有些情况服务器会直接使用磁盘临时表

  • 表里存在BLOB或者TEXT的时候(这是因为MEMORY引擎不支持这两种数据类型,这里笔者补充一下,并非只要查询里含有BLOB和TEXT类型的列就会产生磁盘临时表,按照高性能MYSQL里的话,应该这么说:“Because the Memory storage engine doesn‘t support the BLOB and TEXT types, queries that use BLOB or TEXT columns and need an implicit temporary table will have to use on-disk MyISAM temporry tables, even for only a few rows.”也就是说如果我们的查询中包含了BLOB和TEXT的列,而且又需要临时表,这时候临时表就被强制转成使用磁盘临时表,所以此书一直在提醒我们,如果要对BLOB和TEXT排序,应该使用SUBSTRING(column, length)将这些列截断变成字符串,这样就可以使用in-memory临时表了
  • GROUP BY 或者 DISTINCT 子句大小超过 512 Bytes
  • 使用了UNION 或 UNION ALL 并且 SELECT 的列里有超过512 Bytes的列

如果内置内存临时表创建后变得太大,MySQL会自动将它转换成磁盘临时表。内存临时表的大小取决与 tmp_table_size参数和max_heap_table_size参数的值。用 CREATE TABLE 产生的内存临时表的大小取决与 max_heap_table_size来决定是否要将其转换成磁盘临时表

当服务器生成一个内存临时表,Created_tmp_tables状态变量值会增加,当服务器创建了一个磁盘临时表时,Created_tmp_disk_tables状态变量值会增加。(这几个变量可以通过 show status命令查看得到)

Tips: internal temporaray table 的大小受限制的是tmp_table_size和max_heap_table_size的最小值;而 user-created temporary table的大小只受限与max_heap_table_size,而与tmp_table_size无关

原文地址:https://www.cnblogs.com/jpfss/p/9156525.html

时间: 2024-10-08 11:05:40

mysql using filesort Using temporary的相关文章

Why does MySQL produce so many temporary MYD files?

http://dba.stackexchange.com/questions/30505/why-does-mysql-produce-so-many-temporary-myd-files Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from o

MySQL调优 —— Using temporary

DBA发来一个线上慢查询问题, SQL如下(为突出重点省略部分内容): select distinct article0_.id, 等字段 from article_table article0_, hits_table articlehit1_ where article0_.id=articlehit1_.id order by hits; EXPLAIN结果:耗时4.03S 出乎意料, 竟然会有Using temporary, order by只用到了一张表, 正常情况下不会出现借助辅助表

转载(MySQL Order By实现原理分析和Filesort优化)

在MySQL中的ORDER BY有两种排序实现方式: 1.利用有序索引获取有序数据 2.文件排序 在使用explain分析查询的时候,利用有序索引获取有序数据显示Using index.而文件排序显示Using filesort. 1.利用有序索引获取有序数据 取出满足过滤条件作为排序条件的字段,以及可以直接定位到行数据的行指针信息,在 Sort Buffer 中进行实际的排序操作,然后利用排好序的数据根据行指针信息返回表中取得客户端请求的其他字段的数据,再返回给客户端. 这种方式,在使用exp

MYSQL EXPLAIN戏说

我的博客重点部分都是红字指出. MYSQL EXPLAIN 是MYSQL执行计划查询器,一句话:告诉你MYSQL如何检索数据的.它是告诉你了,但是你能不能看懂又是另外一回事了. 前人种树,后人乘凉:http://www.cnblogs.com/ggjucheng/archive/2012/11/11/2765237.html 上面这个链接对于MYSQL EXPLAIN的解释非常易懂,如果看不懂这个,也不用看我的了. 额外做一些补充说明: 1.type字段:有些地方翻译成“链接类型”.“访问类型”

MySQL索引背后的数据结构及算法原理(下)

为了讨论索引策略,需要一个数据量不算小的数据库作为示例.本文选用MySQL官方文档中提供的示例数据库之一:employees.这个数据库关系复杂度适中,且数据量较大.下图是这个数据库的E-R关系图(引用自MySQL官方手册): 下载文件后使用下面的语句将数据库导入: tar -xjf $HOME/Downloads/employees_db-full-1.0.4.tar.bz2 //解压缩,进入目录 cd employees_db/ //导入数据库root为用户名 mysql -t -u roo

Internal Temporary Tables

8.4.4 How MySQL Uses Internal Temporary Tables 这是MySQL手册中的一节,尝试补充了一些解释.用的版本是MySQL5.6.15社区版 In some cases, the server creates internal temporary tables while processing queries. Such a table can be held in memory and processed by the MEMORY storage en

[MySQL Reference Manual] 8 优化

8.优化 8.优化... 1 8.1 优化概述... 1 8.2 优化SQL语句... 1 8.2.1 优化SELECT语句... 1 8.2.1.1 SELECT语句的速度... 1 8.2.1.2 WHERE子句优化... 1 8.2.1.3 Range优化... 1 8.2.1.4 索引合并(Index Merge)优化... 1 8.2.1.5 引擎Pushdown条件优化... 1 8.2.1.6 索引条件Pushdown优化... 1 8.2.1.7 使用索引扩展... 1 8.2.

Mysql Explain的简单使用

Mysql Explain 主要重要的字段有上面红色方框圈出来的那几个. type: 连接类型,一个好的SQL语句至少要达到range级别,杜绝出现all级别. key: 使用到的索引名,如果没有选择索引,值是NULL.可以采取强制索引方式. key_len: 索引长度. rows: 扫描行数,该值是一个预估值. extra: 详细说明,注意常见不太友好的值,如下:Using filesort, Using temporary. Type 可能的值如下 ALL: 最坏的情况,全表扫描. inde

mysql案例分析

工作中,需要设计一个数据库存储,项目的需求大致如下: (1)对于每个用户,需要存储一个或多个库, 每个库, 由一个用户标识来标识,这里成为clientFlag. (2) 对于每一个库,结构如下: 1) 一个clientFlag对应多个组,组包括组名和组的描述一类的信息 2)一个组中有多个成员,每个成员包括成员名和成员描述一类的信息 3)一个成员包括若干张自己喜欢的图片,图片有图片的文件ID和图片的描述信息 4)每张图片对应于多个版本,每个版本下存储使用深度学习引擎生成的特征 这个需求的目的是,给