mysql执行计划

explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 先解析一条sql语句，看出现什么内容 EXPLAIN SELECT s . uid , s . username , s . name , f . email , f . mobile , f . phone , f . postalcode , f . address FROM uchome_space AS s , uchome_spacefield AS f WHERE 1 AND s . groupid = 0 AND s . uid = f . uid 1. id SELECT识别符。这是SELECT查询序列号。这个不重要,查询序号即为sql语句执行的顺序，看下面这条sql EXPLAIN SELECT * FROM ( SELECT * FROM uchome_space LIMIT 10 ) AS s 它的执行结果为 可以看到这时的id变化了 2.select_type select类型，它有以下几种值 2.1 simple 它表示简单的select,没有union和子查询 2.2 primary 最外面的select,在有子查询的语句中，最外面的select查询就是primary,上图中就是这样 2.3 union

实际项目开发中，由于我们不知道实际查询的时候数据库里发生了什么事情，数据库软件是怎样扫描表、怎样使用索引的，因此，我们能感知到的就只有 sql语句运行的时间，在数据规模不大时，查询是瞬间的，因此，在写sql语句的时候就很少考虑到性能的问题。但是当数据规模增大，如千万、亿的时候，我们运 行同样的sql语句时却发现迟迟没有结果，这个时候才知道数据规模已经限制了我们查询的速度。所以，查询优化和索引也就显得很重要了。 问题： 当我们在查询前能否预先估计查询究竟要涉及多少行、使用哪些索引、运行时间呢？答案是能的，mysql提供了相应的功能和语法来实现该功能。 分析： MySql提供了EXPLAIN语法用来进行查询分析，在SQL语句前加一个"EXPLAIN"即可。比如我们要分析如下SQL语句： explain select * from table where table.id = 1 运行上面的sql语句后你会看到，下面的表头信息： table | type | possible_keys | key | key_len | ref | rows | Extra EXPLAIN列的解释 table 显示这一行的数据是关于哪张表的 type 这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL 说明

引言： 实际项目开发中，由于我们不知道实际查询的时候数据库里发生了什么事情，数据库软件是怎样扫描表、怎样使用索引的，因此，我们能感知到的就只有 sql语句运行的时间，在数据规模不大时，查询是瞬间的，因此，在写sql语句的时候就很少考虑到性能的问题。但是当数据规模增大，如千万、亿的时候，我们运 行同样的sql语句时却发现迟迟没有结果，这个时候才知道数据规模已经限制了我们查询的速度。所以，查询优化和索引也就显得很重要了。 问题： 当我们在查询前能否预先估计查询究竟要涉及多少行、使用哪些索引、运行时间呢？答案是能的，mysql提供了相应的功能和语法来实现该功能。 分析： MySql提供了EXPLAIN语法用来进行查询分析，在SQL语句前加一个"EXPLAIN"即可。比如我们要分析如下SQL语句： explain select * from table where table.id = 1 运行上面的sql语句后你会看到，下面的表头信息： table | type | possible_keys | key | key_len | ref | rows | Extra EXPLAIN列的解释 table 显示这一行的数据是关于哪张表的 type 这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL 说明

索引 一、索引的介绍 数据库中专门用于帮助用户快速查找数据的一种数据结构。类似于字典中的目录，查找字典内容时可以根据目录查找到数据的存放位置吗，然后直接获取。 二、索引的作用 约束和加速查找 三、常见的几种索引 - 普通索引 - 唯一索引 - 主键索引 - 联合索引（多列） - 联合主键索引 　 - 联合唯一索引 　　 - 联合普通索引 无索引和有索引的区别以及建立索引的目的 无索引： 从前往后一条一条查询 有索引：创建索引的本质，就是创建额外的文件（某种格式存储，查询的时候，先去格外的文件找，定好位置，然后再去原始表中直接查询。但是创建索引越多，会对硬盘也是有损耗。 建立索引的目的： a.额外的文件保存特殊的数据结构 b.查询快，但是插入更新删除依然慢 c.创建索引之后，必须命中索引才能有效 1、普通索引 作用：仅有一个加速查找 创建表+普通索引： create table userinfo( nid int not null auto_increment primary key, name varchar(32) not null, email varchar(64) not null, index ix_name(name) ); 普通索引： create index 索引的名字 on 表名(列名) 删除索引： drop index 索引的名字 on 表名 查看索引：

1.1 前言 　 在进行MySQL的优化之前必须要了解的就是MySQL的查询过程，很多的查询优化工作实际上就是遵循一些原则让MySQL的优化器能够按照预想的合理方式运行而已。更多关于MySQL查询相关参照： http://www.cnblogs.com/clsn/p/8038964.html#_label6 系列文章。 图 - MySQL查询过程 1.2 优化的哲学 优化有风险，涉足需谨慎 1.2.1 优化可能带来的问题 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统。 优化手段本来就有很大的风险，只不过你没能力意识到和预见到！ 任何的技术可以解决一个问题，但必然存在带来一个问题的风险！ 对于优化来说解决问题而带来的问题,控制在可接受的范围内才是有成果。 保持现状或出现更差的情况都是失败！ 1.2.2 优化的需求 稳定性和业务可持续性,通常比性能更重要！ 优化不可避免涉及到变更，变更就有风险！ 优化使性能变好，维持和变差是等概率事件！ 切记优化,应该是各部门协同，共同参与的工作，任何单一部门都不能对数据库进行优化！ 所以优化工作,是由业务需要驱使的！！！ 1.2.3 优化由谁参与 　　在进行数据库优化时，应由数据库管理员、业务部门代表、应用程序架构师、应用程序设计人员、应用程序开发人员、硬件及系统管理员、存储管理员等，业务相关人员共同参与。 1.3 优化思路 1

MySQL 查询优化 - 关联查询 1. 关联查询执行流程 MySQL 执行关联查询的策略很简单，他会从一个表中循环取出单条数据，然后用该条数据到下一个表中寻找匹配的行，然后回溯到上一个表，到所有的数据匹配完成为止。因此也被称为“ 嵌套循环关联 ”。 来看下面这个SQL： select tb1.col1, tb2,col2 from tb1 inner join tb2 using(col3) where tb1.col1 in (5,6) 他的执行顺序为（伪代码）： List outerDataList = "select * from tb1 where col1 in (5,6)" for(outerData in outerDataList){ List innerDataList = "select * from tb2 where col3 = outerData.col3" for(innerData : innerDataList){ output(outterData,innerData) } } MySQL认为 所有的查询都是一次关联查询 ，所以如果查询一个表，上述过程也适合，不过只需要完成上面外层的基本操作。 再来看看 left outter join 查询的过程，SQL如下： select tb1.col1, tb2,col2 from tb1 left

学习笔记用，转在咕泡学院 文章目录 存储引擎 存储引擎介绍 CSV存储引擎 Archive存储引擎 Memory存储引擎 Innodb 对比 MySQL体系结构及运行机制 Mysql体系 MySQL查询优化 1 mysql客户端/服务端通信 2 查询缓存 **工作原理：** **判断标准：** 查询缓存配置 mysql默认关闭缓存开启 使用业务场景 3 查询优化处理 4 查询执行引擎 5 返回客户端 执行计划 查询优化器找到最优执行计划 查询执行计划 **执行计划-id** 执行计划-select_type 执行计划-table 执行计划-type（索引） 执行计划-possible_keys、key、rows、filtered 执行计划-Extra 定位慢sql 慢查询日志配置 慢查询日志分析 慢查询日志分析工具 存储引擎 存储引擎介绍 1，插拔式的插件方式 2，存储引擎是指定在表之上的，即一个库中的每一个表都可以指定专用的存储引擎。 3，不管表采用什么样的存储引擎，都会在数据区，产生对应的一个frm文件（表结构定义描述文件） CSV存储引擎 数据存储以CSV文件 特点： 不能定义没有索引、列定义必须为 NOT NULL 、不能设置自增列 ​ 不适用大表或者数据的在线处理 CSV数据的存储用,隔开，可直接编辑CSV文件进行数据的编排 ​ 数据安全性低 注：编辑之后，要生效使用

一. mysql框架和基本介绍 1. 框架图 更详细： 2. 存储引擎 MYISAM与INNODB对比： MYISAM：mysql5.1及以前版本的默认存储引擎。支持全文检索，压缩，表级锁等，但不支持事务，行级锁，崩溃后的数据恢复等 INNODB：mysql5.5及之后的默认存储引擎。支持事务，行级锁，数据恢复，mysql5.6 中的innodb(1.2)支持全文检索。 如何选择：innodb对于绝大多数的用户都是最佳的选择，除非某些存储引擎能满足特殊需求且使用者很了解这种存储引擎。 二. 查询性能的方法 1. 配置文件 my.cnf (linux), 读配置文件的一般顺序： 1) /etc/my.cnf 2) DATADIR/my.cnf 3) ~/.my.cnf 可以通过命令获知： mysqld --verbose --help | grep -A 1 'Default options’ 结果： /etc/my.cnf /etc/mysql/my.cnf /usr/local/mysql/etc/my.cnf ~/.my.cnf 2. 环境变量 从my,cnf读取环境变量值， 查看变量值方法： show variables like “”, (不清楚变量名时，用模糊匹配%) 例如 设置(全局)变量方法： set (global) 变量名=变量值 例如设置 开启慢查询日志 set

explain模拟优化器执行sql语句。 显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句 常常用到explain这个命令来查看一个这些SQL语句的执行计划，查看该SQL语句有没有使用上了索引，有没有做全表扫描 使用方法：在select语句前加上explain就可以了 例如： explain select * from user u left join company c on c.id=u.company_id; expain出来的信息有11列，分别是id、select_type、table、type、possible_keys、key、key_len、ref、rows、filtered、Extra 概要描述： id:选择标识符 select_type:表示查询的类型。 table:输出结果集的表 partitions:匹配的分区 type:表示表的连接类型 possible_keys:表示查询时，可能使用的索引 key:表示实际使用的索引 key_len:索引字段的长度 ref:列与索引的比较 rows:扫描出的行数(估算的行数) filtered:按表条件过滤的行百分比 Extra:执行情况的描述和说明 解释： id：sql执行顺序的标识，sql从大到小的执行 id相同时，执行顺序由上至下 如果是子查询

背景： 做为一个DBA，或者从事数据库相关工作的小伙伴，常见的工作就是优化sql，查看执行计划！但有时优化器给出的执行计划是错误或者不是最优的， 这时我们就要去追踪一下优化执行计划生成的过程。mysql 5.6提供了Tracing the Optimizer 功能这可是优化sql的一大神器 一，开启Tracing the Optimizer set optimizer_trace_max_mem_size=300000; set end_markers_in_json=true; SET optimizer_trace="enabled=on"; 二，生成sql 跟踪信息 explain select * from test.t1; SELECT * FROM information_schema.optimizer_trace; --备注：这个视图就有我们想要信息，内容如下： 三，举例： 比如说sql 会因为Limit 不同的值，执行计划会不一样： 四，结总： 这里面的内容非常多，我在这只是抛砖引玉，大家可以自己去深入了角 ========================================================================== 官网地址： https://dev.mysql.com/doc/internals/en/tracing