mysql 执行计划优化

一条简单的SQL 语句竟花了15.87 sec,

写道

mysql> SELECT x.loc AS loc, x.lastmod AS lastmod, x.changefreq AS changefreq, x.changecount AS changecount, x.priority AS priority, x.language AS language, x.ac cess AS access, x.status AS status FROM xmlsitemap x WHERE (x.access = '1') AND (x.status = '1') ORDER BY x.language DESC, x.loc ASC LIMIT 5 OFFSET 455000 ; +-------------+------------+------------+-------------+----------+----------+--------+--------+ | loc | lastmod | changefreq | changecount | priority | language | access | status | +-------------+------------+------------+-------------+----------+----------+--------+--------+ | node/539675 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539676 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539677 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539678 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539679 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | +-------------+------------+------------+-------------+----------+----------+--------+--------+ 5 rows in set (15.87 sec)

分析一下执行计划

写道

mysql> explain SELECT x.loc AS loc, x.lastmod AS lastmod, x.changefreq AS changefreq, x.changecount AS changecount, x.priority AS priority, x.language AS langua ge, x.access AS access, x.status AS status FROM xmlsitemap x WHERE (x.access = '1') AND (x.status = '1') ORDER BY x.language DESC, x.loc ASC LIMIT 50 OFFS ET 455000; +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-----------------------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-----------------------------+ | 1 | SIMPLE | x | ref | access_status_loc | access_status_loc | 2 | const,const | 266873 | Using where; Using filesort | +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-----------------------------+ 1 row in set (0.00 sec)

从执行计划中可以看到,用到了Using filesort

Using filsort文档中的解释:

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

简单修改去掉

ORDER BY x.language DESC,

分析执行计划

写道

mysql> explain SELECT x.loc AS loc, x.lastmod AS lastmod, x.changefreq AS changefreq, x.changecount AS changecount, x.priority AS priority, x.language AS langua ge, x.access AS access, x.status AS status FROM xmlsitemap x WHERE (x.access = '1') AND (x.status = '1') ORDER BY x.loc ASC LIMIT 5 OFFSET 455000; +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-------------+ | 1 | SIMPLE | x | ref | access_status_loc | access_status_loc | 2 | const,const | 266873 | Using where | +----+-------------+-------+------+-------------------+-------------------+---------+-------------+--------+-------------+ 1 row in set (0.00 sec)

没有用到Using filsort

写道

mysql> SELECT x.loc AS loc, x.lastmod AS lastmod, x.changefreq AS changefreq, x.changecount AS changecount, x.priority AS priority, x.language AS language, x.ac cess AS access, x.status AS status FROM xmlsitemap x WHERE (x.access = '1') AND (x.status = '1') ORDER BY x.loc ASC LIMIT 5 OFFSET 455000; +-------------+------------+------------+-------------+----------+----------+--------+--------+ | loc | lastmod | changefreq | changecount | priority | language | access | status | +-------------+------------+------------+-------------+----------+----------+--------+--------+ | node/539675 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539676 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539677 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539678 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | | node/539679 | 1361158321 | 0 | 0 | 0.8 | und | 1 | 1 | +-------------+------------+------------+-------------+----------+----------+--------+--------+ 5 rows in set (1.14 sec)

只用1.14 sec就执行完了, 快了很多倍!

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/MySQL/

时间: 2025-01-21 04:36:32

mysql 执行计划优化的相关文章

mysql执行计划介绍_Mysql

烂sql不仅直接影响sql的响应时间,更影响db的性能,导致其它正常的sql响应时间变长.如何写好sql,学会看执行计划至关重要.下面我简单讲讲mysql的执行计划,只列出了一些常见的情况,希望对大家有所帮助. 测试表结构: 复制代码 代码如下: CREATE TABLE `t1` (  `c1` int(11) NOT NULL DEFAULT '0',  `c2` varchar(128) DEFAULT NULL,  `c3` varchar(64) DEFAULT NULL,  `c4`

MySQL执行计划extra中的using index 和 using where using index 的区别

原文:MySQL执行计划extra中的using index 和 using where using index 的区别   本文出处:http://www.cnblogs.com/wy123/p/7366486.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)   mysql执行计划中的extra列中表明了执行计划的每一步中的实现细节,其中包含了与索引相关的一些细节信息其中跟索引有关的using index

通过分析SQL语句的执行计划优化SQL_MsSql

如何干预执行计划 - - 使用hints提示 基于代价的优化器是很聪明的,在绝大多数情况下它会选择正确的优化器,减轻了DBA的负担.但有时它也聪明反被聪明误,选择了很差的执行计划,使某个语句的执行变得奇慢无比.此时就需要DBA进行人为的干预,告诉优化器使用我们指定的存取路径或连接类型生成执行计划,从而使语句高效的运行.例如,如果我们认为对于一个特定的语句,执行全表扫描要比执行索引扫描更有效,则我们就可以指示优化器使用全表扫描.在Oracle中,是通过为语句添加hints(提示)来实现干预优化器优

第六章——根据执行计划优化性能(3)——键值查找

原文:第六章--根据执行计划优化性能(3)--键值查找 前言:         本文为本系列最后一篇,介绍键值查找的相关知识.         键值查找是具有聚集索引的表上的一个书签查找,键值查找用于SQLServer查询一些非键值列的数据.使用非聚集索引的查询不会有键值查找,但是所有键值查找会伴随非聚集索引出现.这里特别提醒的是键值查找总是伴有嵌套循环关联.   准备工作:   下面将创建一个表,通过执行计划看看键值查找的不同效果.为了产生键值查找,需要两件事情: 1.  聚集索引 2.  非

第六章——根据执行计划优化性能(1)——理解哈希、合并、嵌套循环连接策略

原文:第六章--根据执行计划优化性能(1)--理解哈希.合并.嵌套循环连接策略 前言: 本系列文章包括: 1. 理解Hash.Merge.Nested Loop关联策略. 2. 在执行计划中发现并解决表/索引扫描. 3. 介绍并在执行计划中发现键查找并解决它们.   对于性能优化,需要集中处理以下的问题: 1. 为你的环境创建性能基线. 2. 监控现在的性能并发现瓶颈. 3. 解决瓶颈以便得到更好的性能.   一个预估执行计划是描述查询将会如何执行的一个蓝图,而一个实际执行计划就是一个查询执行时

Pig源码分析: 逻辑执行计划优化

Whole View 本文分析的是逻辑执行计划优化的代码结构,具体每种Rule的实现不做分析. 看本文之前最好参考之前那篇逻辑执行计划模型的文章. Architecture 几个关键类/接口的关系: 每个关键类/接口的实现和继承结构在下面各节展开. Optimizer PlanOptimizer是抽象类,主要和Rule.PlanTransformListener.OperatorPlan打交道. public abstract class PlanOptimizer { protected Li

第六章——根据执行计划优化性能(2)——查找表/索引扫描

原文:第六章--根据执行计划优化性能(2)--查找表/索引扫描 前言:       在绝大部分情况下,特别是从一个大表中返回少量数据时,表扫描或者索引扫描并不是一种高效的方式.这些必须找出来并解决它们从而提高性能,因为扫描将遍历每一行,查找符合条件的数据,然后返回结果.这种处理是相当耗时耗资源的.在性能优化过程中,一般集中于: 1.  CPU 2.  Network 3.  磁盘IO 而扫描操作会增加这三种资源的开销.   准备工作: 下面将创建两个表来查看不同的物理关联操作的不同影响.创建脚本

通过分析SQL语句的执行计划优化SQL(二)

优化|语句|执行 第5章 ORACLE的执行计划 背景知识:        为了更好的进行下面的内容我们必须了解一些概念性的术语: 共享sql语句    为了不重复解析相同的SQL语句(因为解析操作比较费资源,会导致性能下降),在第一次解析之后,ORACLE将SQL语句及解析后得到的执行计划存放在内存中.这块位于系统全局区域SGA(system global area)的共享池(shared buffer pool)中的内存可以被所有的数据库用户共享.因此,当你执行一个SQL语句(有时被称为一个

MySQL执行计划explain的key_len解析

当用Explain查看SQL的执行计划时,里面有列显示了 key_len 的值,根据这个值可以判断索引的长度,在组合索引里面可以更清楚的了解到了哪部分字段使用到了索引.下面演示中,表结构的合理性这边暂且不说,只是证明一下索引长度的计算方法.目前大部分博文是字符类型的索引长度计算方法,下面列举几个类型的索引长度计算方法: 1.整数类型 (dg1)root@127.0.0.1 [mytest]> desc table_key; +---------+-------------+------+----