mysql执行计划

前言 Hello我又来了，快年底了，作为一个有抱负的码农，我想给自己攒一个年终总结。自上上篇写了 手动搭建Redis集群和MySQL主从同步(非Docker) 和上篇写了 动手实现MySQL读写分离and故障转移 之后，索性这次把数据库中最核心的也是最难搞懂的内容，也就是索引，分享给大家。 这篇博客我会谈谈对于索引结构我自己的看法，以及分享如何从零开始一层一层向上最终理解索引结构。 从一个简单的表开始 create table user( id int primary key, age int, height int, weight int, name varchar(32) )engine = innoDb; 相信只要入门数据库的同学都可以理解这个语句，我们也将从这个最简单的表开始，一步步地理解MySQL的索引结构。 首先，我们往这个表中插入一些数据。 INSERT INTO user(id,age,height,weight,name)VALUES(2,1,2,7,'小吉'); INSERT INTO user(id,age,height,weight,name)VALUES(5,2,1,8,'小尼'); INSERT INTO user(id,age,height,weight,name)VALUES(1,4,3,1,'小泰'); INSERT INTO user(id

1、存储过程的简介： 我们常用的操作数据库语言SQL语句在执行的时候需要要先编译，然后执行，而存储过程（Stored Procedure）是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它。 一个存储过程是一个可编程的函数，它在数据库中创建并保存。它可以有SQL语句和一些特殊的控制结构组成。当希望在不同的应用程序或平台上执行相同的函数，或者封装特定功能时，存储过程是非常有用的。数据库中的存储过程可以看做是对编程中面向对象方法的模拟。它允许控制数据的访问方式。 2、存储过程的有点： (1).存储过程增强了SQL语言的功能和灵活性。存储过程可以用流控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。 (2).存储过程允许标准组件是编程。存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。 (3).存储过程能实现较快的执行速度。如果某一操作包含大量的Transaction-SQL代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的。在首次运行一个存储过程时查询，优化器对其进行分析优化，并且给出最终被存储在系统表中的执行计划。而批处理的Transaction

1.1. EXPLAIN 在MySQL中可以使用EXPLAIN查看SQL执行计划。示例：EXPLAIN SELECT * FROM tb_item 1.2. 结果说明 1.2.1. id SELECT识别符。这是SELECT查询序列号。这个不重要。 1.2.2. select_type 表示SELECT语句的类型。 有以下几种值： 1、 SIMPLE 表示简单查询，其中不包含连接查询和子查询。 2、 PRIMARY 表示主查询，或者是最外面的查询语句。示例：explain select * from (select * from user_t ) as tmp; 3、 UNION 表示连接查询的第2个或后面的查询语句。示例：EXPLAIN SELECT id from user_t UNION select id from role; 4、 DEPENDENT UNION UNION中的第二个或后面的SELECT语句，取决于外面的查询。 5、 UNION RESULT 连接查询的结果。 6、 SUBQUERY 子查询中的第1个SELECT语句。 7、 DEPENDENT SUBQUERY 子查询中的第1个SELECT语句，取决于外面的查询。 8、 DERIVED SELECT(FROM 子句的子查询)。 1.2.3. table 表示查询的表。 1.2.4. type（ 重要 ）

此文是根据杨尚刚在【QCON高可用架构群】中，针对MySQL在单表海量记录等场景下，业界广泛关注的MySQL问题的经验分享整理而成，转发请注明出处。 杨尚刚，美图公司数据库高级DBA，负责美图后端数据存储平台建设和架构设计。前新浪高级数据库工程师，负责新浪微博核心数据库架构改造优化，以及数据库相关的服务器存储选型设计。 前言 MySQL数据库大家应该都很熟悉，而且随着前几年的阿里的去IOE，MySQL逐渐引起更多人的重视。 MySQL历史 1979年，Monty Widenius写了最初的版本，96年发布1.0 1995-2000年，MySQL AB成立，引入BDB 2000年4月，集成MyISAM和replication 2001年，Heikki Tuuri向MySQL建议集成InnoDB 2003发布5.0，提供了视图、存储过程等功能 2008年，MySQL AB被Sun收购，09年推出5.1 2009年4月，Oracle收购Sun，2010年12月推出5.5 2013年2月推出5.6 GA，5.7开发中 MySQL的优点 使用简单 开源免费 扩展性“好”，在一定阶段扩展性好 社区活跃 性能可以满足互联网存储和性能需求，离不开硬件支持 上面这几个因素也是大多数公司选择考虑MySQL的原因。不过MySQL本身存在的问题和限制也很多，有些问题点也经常被其他数据库吐槽或鄙视

在参与实际项目中，当 MySQL 表的数据量达到百万级时，普通的 SQL 查询效率呈直线下降，而且如果 where 中的查询条件较多时，其查询速度无法容忍。想想可知，假如我们查询淘宝的一个订单详情，如果查询时间高达几十秒，这么高的查询延时，任何用户都会抓狂。因此如何提高 SQL 语句查询效率，显得十分重要。 查询速度慢的原因 1、没有索引或者没有用到索引（这是查询慢最常见的问题，是程序设计的缺陷） 2、I/O 吞吐量小，形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大（可采用多次查询，其他的方法降低数据量） 7、锁或者死锁（这是查询慢最常见的问题，是程序设计的缺陷） 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好，没有优化 30 种 SQL 查询语句的优化方法： 1、应尽量避免在 where 子句中使用 != 或者 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。 2、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： 1 select id from t where num is null ; 可以在 num 上设置默认值 0 ，确保表中 num 列没有 null 值，然后这样查询： 1

使用EXPLAIN关键字可以模拟优化器执行SQL语句，从而知道MySQL是 如何处理你的SQL语句的。分析你的查询语句或是结构的性能瓶颈 下面是使用 explain 的例子： 在 select 语句之前增加 explain 关键字，MySQL 会在查询上设置一个标记，执行查询时，会返回执行计划的信息，而不是执行这条SQL（如果 from 中包含子查询，仍会执行该子查询，将结果放入临时表中） 使用的表 DROP TABLE IF EXISTS `actor`; CREATE TABLE `actor` ( `id` int(11) NOT NULL, `name` varchar(45) DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; INSERT INTO `actor` (`id`, `name`, `update_time`) VALUES (1,'a','2017-12-22 15:27:18'), (2,'b','2017-12-22 15:27:18'), (3,'c','2017-12-22 15:27:18'); DROP TABLE IF EXISTS `film`; CREATE TABLE

MySQL查询优化器执行查询的过程中对查询计划的重要补充信息。 （1）using where 使用了where子句来过滤元组 （2）using temporary 用临时表保存中间结果，常用于GROUP BY 和 ORDER BY操作中 （3）using filesort 使用文件完成排序操作，这是可能是ordery by，group by语句的结果，这可能是一个CPU密集型的过程，可以通过选择合适的索引来改进性能，用索引来为查询结果排序。 （4）using index 不需要读取数据文件，从索引树（索引文件）中即可获得信息。如果同时出现using where，表明索引被用来执行索引键值的查找，没有using where，表明索引用来读取数据而非执行查找动作。 （5）using join buffer 使用了连接缓存： Block Nested Loop，连接算法是块嵌套循环连接 Batched Key Access，连接算法是批量索引连接 （6）impossible where where子句的值总是false，不能用来获取任何元组 （7）select tables optimized away 在没有GROUP BY子句的情况下，基于索引优化MIN/MAX操作，或者对于MyISAM存储引擎优化COUNT(*)操作，不必等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化。

索引使用的注意事项(策略及优化) 并不是建立索引就能显著提高查询速度，在索引的使用过程中，存在一些使用细节和注意事项，因为稍不留心，就可能导致在查询过程中索引失效。 一下列举一些需要注意的事项： 1. 不要在列上使用函数 不要在列上使用函数，这将导致索引失效而进行全表扫描。 如： 1 select * from news where year(publish_time) < 2018 应改为： 1 select * from news where publish_time < '2018-01-01' 2. 不要在列上进行计算 不要在列上进行运算，这也将导致索引失效而进行全表扫描。 如： 1 select * from news where id / 100 = 1 应改为： 1 select * from news where id = 1 * 100 3. 尽量避免使用 != 或 not in或 <> 等否定操作符 应该尽量避免在 where 子句中使用 != 或 not in 或 <>操作符， 这些负向查询也会导致索引失效而进行全表扫描。 如： 1 select name from user where id not in (1,3,4); 应改为: 1 select name from user where id in (2,5,6); 4. 尽量避免使用 or 来连接条件

本篇文章是对MySQL中优化sql语句查询常用的30种方法进行了详细的分析介绍，需要的朋友参考下 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%' 若要提高效率，可以考虑全文检索。 6.in 和 not in 也要慎用，否则会导致全表扫描，如： select id

关于MySQL隐式转换 一、如果表定义的是 varchar 字段，传入的是数字，则会发生隐式转换。 1 、表 DDL 2 、传 int 的 sql 3 、传字符串的 sql 仔细看下表结构， rid 的字段类型： 而用户传入的是 int ，这里会有一个隐式转换的问题，隐式转换会导致全表扫描。 把输入改成字符串类型，执行计划如下，这样就会很快了。 此外，还需要注意的是： 数字类型的 0001 等价于 1 字符串的 0001 和 1 不等价 二、如果表定义的是 int 字段，传入的是字符串，在不超过 int 范围内，不会发生隐式转换，如果超出范围并且比较大小（以字符串类型比较 '$' ）会隐式转换。 1 、表 DDL 2 、不超范围传字符串的 sql 3 、不超范围传数字的 sql 4 、超出范围传字符串的 sql 5 、超出范围传数字的 sql 转载于:https://blog.51cto.com/jialong/1884259 来源： CSDN 作者： weixin_34200628 链接： https://blog.csdn.net/weixin_34200628/article/details/91628496