当前位置:首页 » 编程语言 » 分析sql语句查询效率的语句
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

分析sql语句查询效率的语句

发布时间: 2023-04-15 12:13:37

sql查询语句效率提问 对小弟来说非常高深!!!

答案是 : 效率是不同的

From 后面的表:效率最高(记录少,有索引)的表在最后,效率低的表在最左(记录多,无索引)
From 一般都是逆序,比如你的sql语言,数据库会先处理你的table_2

Where 后面的条件:从左到右的顺序,将效率高的比较放在前面(可以过滤更多的数据,从而减少后面条件的处理)
Where 条件一般都是顺序。表连接条件执行效率是比较高的,应该放在前面

所以你的两句sql语言,前者的效率更高。

并且可以改变table_1和Table2的位置让你的效率更高

② 如何查看SqlServer查询语句的执行效率

使用语句查询SQL Server执行过的语句及执行效率

SELECTTOP1000
ST.textAS'执行的SQL语句',
QS.execution_countAS'执行次数',
QS.total_elapsed_timeAS'耗时',
QS.total_logical_readsAS'逻辑读取次数',
QS.total_logical_writesAS'逻辑写入次数',
QS.total_physical_readsAS'物理读取次数',
QS.creation_timeAS'执行时间',
QS.*
FROMsys.dm_exec_query_statsQS
CROSSAPPLY
sys.dm_exec_sql_text(QS.sql_handle)ST
--WHEREQS.creation_timeBETWEEN'2015-08-0100:00:00'AND'2015-09-0211:00:00'
ORDERBY
QS.creation_timeDESC

③ 如何利用MySQL数据库命令查看SQL执行效率

MySQL数据库如何通过命令查看SQL语句执行效率,一般情况下,可以通过命令show status来显示执行SQL效率。下面利用几个实例来说明show status的用法,具体操作如下:
http://jingyan..com/article/597a064357933a312b52438a.html

④ 请简述项目中优化sql语句执行效率的方法,从哪些方面,sql语句性能如何分析

1. SQL优化的原则是:将一次操作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。
调整不良SQL通常可以从以下几点切入:
? 检查不良的SQL,考虑其写法是否还有可优化内容
? 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写
? 检查优化索引的使用
? 考虑数据库的优化器

2. 避免出现SELECT * FROM table 语句,要明确查出的字段。

3. 在一个SQL语句中,如果一个where条件过滤的数据库记录越多,定位越准确,则该where条件越应该前移。

4. 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引,这样查询时只进行索引扫描,不读取数据块。

5. 在判断有无符合条件的记录时建议不要用SELECT COUNT (*)和select top 1 语句。

6. 使用内层限定原则,在拼写SQL语句时,将查询条件分解、分类,并尽量在SQL语句的最里层进行限定,以减少数据的处理量。

7. 应绝对避免在order by子句中使用表达式。

8. 如果需要从关联表读数据,关联的表一般不要超过7个。

9. 小心使用 IN 和 OR,需要注意In集合中的数据量。建议集合中的数据不超过200个。

10. <> 用 < 、 > 代替,>用>=代替,<用<=代替,这样可以有效的利用索引。

11. 在查询时尽量减少对多余数据的读取包括多余的列与多余的行。

12. 对于复合索引要注意,例如在建立复合索引时列的顺序是F1,F2,F3,则在where或order by子句中这些字段出现的顺序要与建立索引时的字段顺序一致,且必须包含第一列。只能是F1或F1,F2或F1,F2,F3。否则不会用到该索引。

13. 多表关联查询时,写法必须遵循以下原则,这样做有利于建立索引,提高查询效率。格式如下select sum(table1.je) from table1 table1, table2 table2, table3 table3 where (table1的等值条件(=)) and (table1的非等值条件) and (table2与table1的关联条件) and (table2的等值条件) and (table2的非等值条件) and (table3与table2的关联条件) and (table3的等值条件) and (table3的非等值条件)。
注:关于多表查询时from 后面表的出现顺序对效率的影响还有待研究。

14. 子查询问题。对于能用连接方式或者视图方式实现的功能,不要用子查询。例如:select name from customer where customer_id in ( select customer_id from order where money>1000)。应该用如下语句代替:select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。

15. 在WHERE 子句中,避免对列的四则运算,特别是where 条件的左边,严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。

16. 如果在语句中有not in(in)操作,应考虑用not exists(exists)来重写,最好的办法是使用外连接实现。

17. 对一个业务过程的处理,应该使事物的开始与结束之间的时间间隔越短越好,原则上做到数据库的读操作在前面完成,数据库写操作在后面完成,避免交叉。

18. 请小心不要对过多的列使用列函数和order by,group by等,谨慎使用disti软件开发t。

19. 用union all 代替 union,数据库执行union操作,首先先分别执行union两端的查询,将其放在临时表中,然后在对其进行排序,过滤重复的记录。
当已知的业务逻辑决定query A和query B中不会有重复记录时,应该用union all代替union,以提高查询效率。

⑤ 如何提高SQL语句的查询效率

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:

select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0
3.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用,否则会导致全表扫描,如:
select id from t where num in(1,2,3)
对于连续的数值,能用 between 就不要用 in 了:
select id from t where num between 1 and 3
6.下面的查询也将导致全表扫描:
select id from t where name like '%abc%'
若要提高效率,可以考虑全文检索。
7.如果在 where 子句中使用参数,也会导致全表扫描。因为SQL只有在运行时才会解析局部变量,但优化程序不能将访问计划的选择推迟到运行时;它必须在编译时进行选择。然而,如果在编译时建立访问计划,变量的值还是未知的,因而无法作为索引选择的输入项。如下面语句将进行全表扫描:
select id from t where num=@num
可以改为强制查询使用索引:
select id from t with(index(索引名)) where num=@num
8.应尽量避免在 where 子句中对字段进行表达式操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where num/2=100
应改为:
select id from t where num=100*2
9.应尽量避免在where子句中对字段进行函数操作,这将导致引擎放弃使用索引而进行全表扫描。如:
select id from t where substring(name,1,3)='abc' // oracle总有的是substr函数。
select id from t where datediff(day,createdate,'2005-11-30')=0 //查过了确实没有datediff函数。
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1' //
oracle 中时间应该把char 转换成 date 如: createdate >= to_date('2005-11-30','yyyy-mm-dd')
10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算,否则系统将可能无法正确使用索引。

11.在使用索引字段作为条件时,如果该索引是复合索引,那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引,否则该索引将不会被使用,并且应尽可能的让字段顺序与索引顺序相一致。
12.不要写一些没有意义的查询,如需要生成一个空表结构:
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集,但是会消耗系统资源的,应改成这样:
create table #t(...)
13.很多时候用 exists 代替 in 是一个好的选择:
select num from a where num in(select num from b)
用下面的语句替换:
select num from a where exists(select 1 from b where num=a.num)
14.并不是所有索引对查询都有效,SQL是根据表中数据来进行查询优化的,当索引列有大量数据重复时,SQL查询可能不会去利用索引,如一表中有字段sex,male、female几乎各一半,那么即使在sex上建了索引也对查询效率起不了作用。
15.索引并不是越多越好,索引固然可以提高相应的 select 的效率,但同时也降低了 insert 及 update 的效率,因为 insert 或 update 时有可能会重建索引,所以怎样建索引需要慎重考虑,视具体情况而定。一个表的索引数最好不要超过6个,若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16.应尽可能的避免更新 clustered 索引数据列,因为 clustered 索引数据列的顺序就是表记录的物理存储顺序,一旦该列值改变将导致整个表记录的顺序的调整,会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列,那么需要考虑是否应将该索引建为 clustered 索引。
17.尽量使用数字型字段,若只含数值信息的字段尽量不要设计为字符型,这会降低查询和连接的性能,并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符,而对于数字型而言只需要比较一次就够了。
18.尽可能的使用 varchar/nvarchar 代替 char/nchar ,因为首先变长字段存储空间小,可以节省存储空间,其次对于查询来说,在一个相对较小的字段内搜索效率显然要高些。
19.任何地方都不要使用 select * from t ,用具体的字段列表代替“*”,不要返回用不到的任何字段。
20.尽量使用表变量来代替临时表。如果表变量包含大量数据,请注意索引非常有限(只有主键索引)。
21.避免频繁创建和删除临时表,以减少系统表资源的消耗。
22.临时表并不是不可使用,适当地使用它们可以使某些例程更有效,例如,当需要重复引用大型表或常用表中的某个数据集时。但是,对于一次性事件,最好使用导出表。
23.在新建临时表时,如果一次性插入数据量很大,那么可以使用 select into 代替 create table,避免造成大量 log ,以提高速度;如果数据量不大,为了缓和系统表的资源,应先create table,然后insert。
24.如果使用到了临时表,在存储过程的最后务必将所有的临时表显式删除,先 truncate table ,然后 drop table ,这样可以避免系统表的较长时间锁定。
25.尽量避免使用游标,因为游标的效率较差,如果游标操作的数据超过1万行,那么就应该考虑改写。
26.使用基于游标的方法或临时表方法之前,应先寻找基于集的解决方案来解决问题,基于集的方法通常更有效。
27.与临时表一样,游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法,尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许,基于游标的方法和基于集的方法都可以尝试一下,看哪一种方法的效果更好。
28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ,在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29.尽量避免大事务操作,提高系统并发能力。
30.尽量避免向客户端返回大数据量,若数据量过大,应该考虑相应需求是否合理。

⑥ MSSQL如何查看sql语句执行时间判断执行效率

写程序的人,往往需要分析所写的SQL语句是否已经优化过了,服务器的响应时间有多快,这个时候就需要用到SQL的STATISTICS状态值来查看了。

通过设置STATISTICS我们可以查看执行SQL时的系统情况。选项有PROFILE,IO ,TIME。介绍如下:

SET STATISTICS PROFILE ON:显示分析、编译和执行查询所需的时间(以毫秒为单位)。
SET STATISTICS IO ON:报告与语句内引用的每个表的扫描数、逻辑读取数(在高速缓存中访问的页数)和物理读取数(访问磁盘的次数)有关的信息。
SET STATISTICS TIME ON:显示每个查询执行后的结果集,代表查询执行的配置文件。

使用方法:打开SQL SERVER 查询分析器,输入以下语句:

SET STATISTICS PROFILE ON
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO /*--你的SQL脚本开始*/
SELECT [TestCase] FROM [TestCaseSelect]
GO /*--你的SQL脚本结束*/
SET STATISTICS PROFILE OFF
SET STATISTICS IO OFF
SET STATISTICS TIME OFF

效果如图所示:

另外,也可以通过手工添加语句,计算执行时间来查看执行语句花费了的时间,以判断该条SQL语句的效率如何:

declare @d datetime
set @d=getdate()
/*你的SQL脚本开始*/
SELECT [TestCase] FROM [TestCaseSelect]
/*你的SQL脚本结束*/
select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

⑦ 查询的SQL语句怎么写才能提高查询效率

这是SQL语句优化的问题了。网上好多类似的文章,非常全面。
个人觉得比较常用的是:
SQL语句查询中经常用到的字段建索引,这样可以非常明显的提升查询速度。
FROM表的顺序,大表在前,小表在后,因为检索的顺序从后往前。
WHERE, WHERE A.COLUMN = B.COLUMN,把小表的字段放在后边(B表),大表在前。
固定值查询的放在后边 COLUMN = '1'这种。因为这个也是从后往前的顺序。
如果有(NOT) IN (SELECT ...) 尽量避免,因为IN里面也是一个大的查询,使用 (NOT) EXISTS的语法代替。
还有UNION和UNION ALL,多表联合,UNION的作用是可以去掉重复,如果多表没有重复数据,使用UNION ALL效率也会大大提高。

⑧ 急急急!!!sql中分析查询查询语句对查询效率的影响

select a.职工号 from 职工 a right join
(select max(月工资) 大月工资 ,部门号 from 职工 group by 部门号) b
on a.月工资 = b.大月工资 where a.部门号=b.部门号
可以取同一部门最高工资的多个职工号

⑨ 优化以下sql语句以提高查询效率(提示:可用子查询)

1.对查询进行优化,应尽量避免全表扫描,首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中使用!=或<>操作符,否则将引擎放弃使用索引而进行全表扫描。

3.应尽量避免在 where 子句中对字段进行 null 值判断,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num is null
可以在num上设置默认值0,确保表中num列没有null值,然后这样查询:
select id from t where num=0

4.应尽量避免在 where 子句中使用 or 来连接条件,否则将导致引擎放弃使用索引而进行全表扫描,如:
select id from t where num=10 or num=20
可以这样查询:
select id from t where num=10
union all
select id from t where num=20

5.下面的查询也将导致全表扫描:
select id from t where name like '%abc%'
若要提高效率,可以考虑全文检索。

⑩ MySQL中如何查看“慢查询”,如何分析执行SQL的效率

一、MySQL数据库有几个配置选项可以帮助我们及时捕获低效SQL语句x0dx0ax0dx0a1,slow_query_logx0dx0a这个参数设置为ON,可以捕获执行时间超过一定数值的SQL语句。x0dx0ax0dx0a2,long_query_timex0dx0a当SQL语句执行时间超过此数值时,就会被记录到日志中,建议设置为1或者更短。x0dx0ax0dx0a3,slow_query_log_filex0dx0a记录日志的文件名。x0dx0ax0dx0a4,log_queries_not_using_indexesx0dx0a这个参数设置为ON,可以捕获到所有未使用索引的SQL语句,尽管这个SQL语句有可能执行得挺快。x0dx0ax0dx0a二、检测mysql中sql语句的效率的方法x0dx0ax0dx0a1、通过查询日志x0dx0a(1)、Windows下开启MySQL慢查询x0dx0aMySQL在Windows系统中的配置文件一般是是my.ini找到[mysqld]下面加上x0dx0a代码如下x0dx0alog-slow-queries = F:/MySQL/log/mysqlslowquery。logx0dx0along_query_time = 2x0dx0ax0dx0a(2)、Linux下启用MySQL慢查询x0dx0aMySQL在Windows系统中的配置文件一般是是my.cnf找到[mysqld]下面加上x0dx0a代码如下x0dx0alog-slow-queries=/data/mysqldata/slowquery。logx0dx0along_query_time=2x0dx0a说明x0dx0alog-slow-queries = F:/MySQL/log/mysqlslowquery。x0dx0a为慢查询日志存放的位置,一般这个目录要有MySQL的运行帐号的可写权限,一般都将这个目录设置为MySQL的数据存放目录;x0dx0along_query_time=2中的2表示查询超过两秒才记录;x0dx0ax0dx0a2.show processlist 命令x0dx0ax0dx0aSHOW PROCESSLIST显示哪些线程正在运行。您也可以使用mysqladmin processlist语句得到此信息。x0dx0a各列的含义和用途:x0dx0aID列x0dx0a一个标识,你要kill一个语句的时候很有用,用命令杀掉此查询 /*/mysqladmin kill 进程号。x0dx0auser列x0dx0a显示单前用户,如果不是root,这个命令就只显示你权限范围内的sql语句。x0dx0ahost列x0dx0a显示这个语句是从哪个ip的哪个端口上发出的。用于追踪出问题语句的用户。x0dx0adb列x0dx0a显示这个进程目前连接的是哪个数据库。x0dx0acommand列x0dx0a显示当前连接的执行的命令,一般就是休眠(sleep),查询(query),连接(connect)。x0dx0atime列x0dx0a此这个状态持续的时间,单位是秒。x0dx0astate列x0dx0a显示使用当前连接的sql语句的状态,很重要的列,后续会有所有的状态的描述,请注意,state只是语句执行中的某一个状态,一个 sql语句,以查询为例,可能需要经过ing to tmp table,Sorting result,Sending data等状态才可以完成x0dx0ainfo列x0dx0a显示这个sql语句,因为长度有限,所以长的sql语句就显示不全,但是一个判断问题语句的重要依据。x0dx0ax0dx0a这个命令中最关键的就是state列,mysql列出的状态主要有以下几种:x0dx0aChecking tablex0dx0a正在检查数据表(这是自动的)。x0dx0aClosing tablesx0dx0a正在将表中修改的数据刷新到磁盘中,同时正在关闭已经用完的表。这是一个很快的操作,如果不是这样的话,就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。x0dx0aConnect Outx0dx0a复制从服务器正在连接主服务器。x0dx0ax0dx0aCopying to tmp table on diskx0dx0a由于临时结果集大于tmp_table_size,正在将临时表从内存存储转为磁盘存储以此节省内存。x0dx0aCreating tmp tablex0dx0a正在创建临时表以存放部分查询结果。x0dx0adeleting from main tablex0dx0a服务器正在执行多表删除中的第一部分,刚删除第一个表。x0dx0adeleting from reference tablesx0dx0a服务器正在执行多表删除中的第二部分,正在删除其他表的记录。x0dx0ax0dx0aFlushing tablesx0dx0a正在执行FLUSH TABLES,等待其他线程关闭数据表。x0dx0aKilledx0dx0a发送了一个kill请求给某线程,那么这个线程将会检查kill标志位,同时会放弃下一个kill请求。MySQL会在每次的主循环中检查kill标志位,不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了,那么kill请求会在锁释放时马上生效。x0dx0aLockedx0dx0a被其他查询锁住了。x0dx0aSending datax0dx0a正在处理SELECT查询的记录,同时正在把结果发送给客户端。x0dx0ax0dx0aSorting for groupx0dx0a正在为GROUP BY做排序。x0dx0aSorting for orderx0dx0a正在为ORDER BY做排序。x0dx0aOpening tablesx0dx0a这个过程应该会很快,除非受到其他因素的干扰。例如,在执ALTER TABLE或LOCK TABLE语句行完以前,数据表无法被其他线程打开。正尝试打开一个表。x0dx0aRemoving plicatesx0dx0a正在执行一个SELECT DISTINCT方式的查询,但是MySQL无法在前一个阶段优化掉那些重复的记录。因此,MySQL需要再次去掉重复的记录,然后再把结果发送给客户端。x0dx0ax0dx0aReopen tablex0dx0a获得了对一个表的锁,但是必须在表结构修改之后才能获得这个锁。已经释放锁,关闭数据表,正尝试重新打开数据表。x0dx0aRepair by sortingx0dx0a修复指令正在排序以创建索引。x0dx0aRepair with keycachex0dx0a修复指令正在利用索引缓存一个一个地创建新索引。它会比Repair by sorting慢些。x0dx0aSearching rows for updatex0dx0a正在讲符合条件的记录找出来以备更新。它必须在UPDATE要修改相关的记录之前就完成了。x0dx0aSleepingx0dx0a正在等待客户端发送新请求.x0dx0ax0dx0aSystem lockx0dx0a正在等待取得一个外部的系统锁。如果当前没有运行多个mysqld服务器同时请求同一个表,那么可以通过增加--skip-external-locking参数来禁止外部系统锁。x0dx0aUpgrading lockx0dx0aINSERT DELAYED正在尝试取得一个锁表以插入新记录。x0dx0aUpdatingx0dx0a正在搜索匹配的记录,并且修改它们。x0dx0ax0dx0aUser Lockx0dx0a正在等待GET_LOCK()。x0dx0aWaiting for tablesx0dx0a该线程得到通知,数据表结构已经被修改了,需要重新打开数据表以取得新的结构。然后,为了能的重新打开数据表,必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知:FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。x0dx0awaiting for handler insertx0dx0aINSERT DELAYED已经处理完了所有待处理的插入操作,正在等待新的请求。x0dx0a大部分状态对应很快的操作,只要有一个线程保持同一个状态好几秒钟,那么可能是有问题发生了,需要检查一下。x0dx0a还有其他的状态没在上面中列出来,不过它们大部分只是在查看服务器是否有存在错误是才用得着。x0dx0ax0dx0a例如如图:x0dx0ax0dx0a3、explain来了解SQL执行的状态x0dx0aexplain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。x0dx0a使用方法,在select语句前加上explain就可以了:x0dx0a例如:x0dx0aexplain select surname,first_name form a,b where a.id=b.idx0dx0a结果如图x0dx0ax0dx0aEXPLAIN列的解释x0dx0atablex0dx0a显示这一行的数据是关于哪张表的x0dx0atypex0dx0a这是重要的列,显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALLx0dx0apossible_keysx0dx0a显示可能应用在这张表中的索引。如果为空,没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句x0dx0akeyx0dx0a实际使用的索引。如果为NULL,则没有使用索引。很少的情况下,MYSQL会选择优化不足的索引。这种情况下,可以在SELECT语句 中使用USE INDEX(indexname)来强制使用一个索引或者用IGNORE INDEX(indexname)来强制MYSQL忽略索引x0dx0akey_lenx0dx0a使用的索引的长度。在不损失精确性的情况下,长度越短越好x0dx0arefx0dx0a显示索引的哪一列被使用了,如果可能的话,是一个常数x0dx0arowsx0dx0aMYSQL认为必须检查的用来返回请求数据的行数x0dx0aExtrax0dx0a关于MYSQL如何解析查询的额外信息。将在表4.3中讨论,但这里可以看到的坏的例子是Using temporary和Using filesort,意思MYSQL根本不能使用索引,结果是检索会很慢x0dx0ax0dx0aextra列返回的描述的意义x0dx0aDistinctx0dx0a一旦MYSQL找到了与行相联合匹配的行,就不再搜索了x0dx0aNot existsx0dx0aMYSQL优化了LEFT JOIN,一旦它找到了匹配LEFT JOIN标准的行,就不再搜索了x0dx0aRange checked for each Record(index map:#)x0dx0a没有找到理想的索引,因此对于从前面表中来的每一个行组合,MYSQL检查使用哪个索引,并用它来从表中返回行。这是使用索引的最慢的连接之一x0dx0aUsing filesortx0dx0a看到这个的时候,查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行x0dx0aUsing indexx0dx0a列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的,这发生在对表的全部的请求列都是同一个索引的部分的时候x0dx0aUsing temporaryx0dx0a看到这个的时候,查询需要优化了。这里,MYSQL需要创建一个临时表来存储结果,这通常发生在对不同的列集进行ORDER BY上,而不是GROUP BY上x0dx0aWhere usedx0dx0a使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行,并且连接类型ALL或index,这就会发生,或者是查询有问题不同连接类型的解释(按照效率高低的顺序排序)x0dx0aconstx0dx0a表中的一个记录的最大值能够匹配这个查询(索引可以是主键或惟一索引)。因为只有一行,这个值实际就是常数,因为MYSQL先读这个值然后把它当做常数来对待x0dx0aeq_refx0dx0a在连接中,MYSQL在查询时,从前面的表中,对每一个记录的联合都从表中读取一个记录,它在查询使用了索引为主键或惟一键的全部时使用x0dx0arefx0dx0a这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分(比如,利用最左边前缀)时发生。对于之前的表的每一个行联合,全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好x0dx0arangex0dx0a这个连接类型使用索引返回一个范围中的行,比如使用>或<查找东西时发生的情况x0dx0aindexx0dx0a这个连接类型对前面的表中的每一个记录联合进行完全扫描(比ALL更好,因为索引一般小于表数据)x0dx0aALLx0dx0a这个连接类型对于前面的每一个记录联合进行完全扫描,这一般比较糟糕,应该尽量避免