mysql执行计划

本文源码： GitHub·点这里 || GitEE·点这里 一、服务器性能简介 1、性能定义 服务器性能优化是一项非常艰巨的任务，当然也是很难处理的问题，在写这篇文章的时候，特意请教下运维大佬，硬件工程师，数据库管理，单从自己的实际开发经验来看，看待这个问题的角度起码是不全面的。 补刀一句 ：在公司靠谱少撕逼，工程师这个群体是很好交朋友的，互相学习一起进步，升职加薪他不好吗？ 服务性能定义：完成一个任务或者处理一次接口请求所需要的时间，这个时间是指响应完成时间，即请求发出，到页面响应回显结束，这是看待性能问题的基本逻辑。 2、分析性能 服务的基本过程一般如下图，这是一张最简单的前后端分离，加一台数据库存储的流程，但是想要说明一个复杂的逻辑。 从页面请求，到获取完整的响应结果，这个过程每个环节都可能导致性能问题，抛开网络，硬件，服务器，MySQL存储这些核心客观因素，单是下面这行代码就可以秒掉很多人的努力。 Thread.sleep(10000); // 仿佛整个世界都安静了。 影响性能的因素很多，一般说性能优化会从下面几个方面考虑： 网络传输，比如私有云和公有云的交互，接口传输内容过大； 应用服务，接口设计是否最简，没有逻辑问题，架构设计是否合理； 存储服务，MySQL的查询写入，表设计是否合理，连接池配置是否合理； 硬件设施，CPU和内存的利用是否在合理区间，缓存是否合理；

概述 MySQL中临时表主要有两类，包括外部临时表和内部临时表。 外部临时表是通过语句create temporary table...创建的临时表，临时表只在本会话有效，会话断开后，临时表数据会自动清理。 内部临时表主要有两类，一类是information_schema中临时表，另一类是会话执行查询时，如果执行计划中包含有“Using temporary”时，会产生临时表。 内部临时表与外部临时表的一个区别在于，我们看不到内部临时表的表结构定义文件frm。 而外部临时表的表定义文件frm，一般是以#sql{进程id}_{线程id}_序列号组成，因此不同会话可以创建同名的临时表。 临时表 临时表与普通表的主要区别在于是否在实例，会话，或语句结束后，自动清理数据。 比如，内部临时表，我们在一个查询中，如果要存储中间结果集，而查询结束后，临时表就会自动回收，不会影响用户表结构和数据。 另外就是，不同会话的临时表可以重名，所有多个会话执行查询时，如果要使用临时表，不会有重名的担忧。 5.7引入了临时表空间后，所有临时表都存储在临时表空间(非压缩)中，临时表空间的数据可以复用。 临时表并非只支持Innodb引擎，还支持myisam引擎，memory引擎等。 因此，临时表我们看不到实体(idb文件)，但其实不一定是内存表，也可能存储在临时表空间中。 临时表 VS 内存表

1.6多个查询字段（常量条件） 多个查询字段的查询处理逻辑如下所示： JOIN:prepare阶段 setup_tables()：同1.1测试。 setup_fields()：同1.1测试。 setup_conds()：同1.4测试。 JOIN:optimize阶段 optimize_cond()：类似1.4测试，不同之处在于查询的where条件中有恒等常量，在优化过程中会调用remove_eq_conds将1=1条件删除。 make_join_statistics()：与1.4测试类似，由于where条件查询有两个，并且其中一个条件可以通过索引查询。因此首先通过调用update_ref_and_keys()（sql\sql_select.cc:3967）函数，查找可以使用索引的字段。 SQL_SELECT::test_quick_select()：同1.5索引测试 get_key_scans_params()：同1.5索引测试。 choose_plan()：同1.3测试。 greedy_search()：同1.3测试。 best_extension_by_limited_search()：同1.5索引测试。 JOIN:exec阶段 以下操作同1.3测试。 通过测试可以看出，对于常量等式对查询优化器来说没有任何意义，会在optimize_conds时将常量等式删除

本文源码： GitHub·点这里 || GitEE·点这里 一、服务器性能简介 1、性能定义 服务器性能优化是一项非常艰巨的任务，当然也是很难处理的问题，在写这篇文章的时候，特意请教下运维大佬，硬件工程师，数据库管理，单从自己的实际开发经验来看，看待这个问题的角度起码是不全面的。 补刀一句 ：在公司靠谱少撕逼，工程师这个群体是很好交朋友的，互相学习一起进步，升职加薪他不好吗？ 服务性能定义：完成一个任务或者处理一次接口请求所需要的时间，这个时间是指响应完成时间，即请求发出，到页面响应回显结束，这是看待性能问题的基本逻辑。 2、分析性能 服务的基本过程一般如下图，这是一张最简单的前后端分离，加一台数据库存储的流程，但是想要说明一个复杂的逻辑。 从页面请求，到获取完整的响应结果，这个过程每个环节都可能导致性能问题，抛开网络，硬件，服务器，MySQL存储这些核心客观因素，单是下面这行代码就可以秒掉很多人的努力。 Thread.sleep(10000); // 仿佛整个世界都安静了。 影响性能的因素很多，一般说性能优化会从下面几个方面考虑： 网络传输，比如私有云和公有云的交互，接口传输内容过大； 应用服务，接口设计是否最简，没有逻辑问题，架构设计是否合理； 存储服务，MySQL的查询写入，表设计是否合理，连接池配置是否合理； 硬件设施，CPU和内存的利用是否在合理区间，缓存是否合理；

一、EXPLAIN 做MySQL优化，我们要善用 EXPLAIN 查看SQL执行计划。 下面来个简单的示例，标注(1,2,3,4,5)我们要重点关注的数据 type列，连接类型。一个好的sql语句至少要达到range级别。杜绝出现all级别 key列，使用到的索引名。如果没有选择索引，值是NULL。可以采取强制索引方式 key_len列，索引长度 rows列，扫描行数。该值是个预估值 extra列，详细说明。注意常见的不太友好的值有：Using filesort, Using temporary 二、SQL语句中IN包含的值不应过多 MySQL对于IN做了相应的优化，即将IN中的常量全部存储在一个数组里面，而且这个数组是排好序的。但是如果数值较多，产生的消耗也是比较大的。再例如：select id from table_name where num in(1,2,3) 对于连续的数值，能用 between 就不要用 in 了；再或者使用连接来替换。 三、SELECT语句务必指明字段名称 SELECT *增加很多不必要的消耗（cpu、io、内存、网络带宽）；增加了使用覆盖索引的可能性；当表结构发生改变时，前断也需要更新。所以要求直接在select后面接上字段名。 四、当只需要一条数据的时候，使用limit 1 这是为了使EXPLAIN中type列达到const类型 五

统计一个表的数据量是经常遇到的需求，但是不同的表设计及不同的写法，统计性能差别会有较大的差异，下面就简单通过实验进行测试( 大家测试的时候注意缓存的情况，否则影响测试结果 ）。 1、 准备工作 为了后续测试工作的进行，先准备几张用于测试的表及数据，为了使测试数据具有参考意义，建议测试表的数据量大一点，以免查询时间太小，因此，可以继续使用之前常用的连续数生成大法，如下： /* 创建连续数表 */ CREATE TABLE nums(id INT primary key); /* 生成连续数的存储过程,优化过后的 */ DELIMITER $$ CREATE PROCEDURE `sp_createNum`(cnt INT ) BEGIN DECLARE i INT DEFAULT 1; TRUNCATE TABLE nums; INSERT INTO nums SELECT i; WHILE i < cnt DO BEGIN INSERT INTO nums SELECT id + i FROM nums WHERE id + i<=cnt; SET i = i*2; END; END WHILE; END$$ DELIMITER ; 生成数据，本次准备生成1kw条记录 /* 调用存储过程 */ mysql> call sp_createNum(10000000); Query OK

Mysql 解释计划 输出字段分为 id select_type table partitions type possible_keys key key_len ref rows filtered extra 1. select_type INSERT DELETE UPDATE 增删改 查有多个 查询的类型，主要是用于区分普通查询、联合查询、子查询等复杂的查询 1、SIMPLE：简单的select查询，查询中不包含子查询或者union （select * from atest1 t1 ） 2、PRIMARY：查询中包含任何复杂的子部分，最外层查询则被标记为primary （select * from atest1 where id = (select id from atest2 ) ） 3、SUBQUERY：在select 或 where列表中包含了子查询 （同上） 4、DERIVED：在from列表中包含的子查询被标记为derived（衍生），mysql或递归执行这些子查询，把结果放在零时表里 2. table 表名 如果有别名，显示别名 3 partitions 查询使用到表分区的分区名。 4.type 核心属性 分为 system > const > eq_ref > ref > range > index > ALL 4.1 system: 无法重现 4.2 const

Q1：MySQL主要有哪些存储引擎，分别适合哪些应用场景？ 答：主要有①MyISAM，是5.5版本之前的默认存储引擎，支持表级锁，不支持事务和外键，并发效率较低，读取数据快，更新数据慢。适合以读操作为主，并且对并发性要求较低的应用。②InnoDB，MySQL目前的默认存储引擎，支持行级锁、事务和外键，并发效率好。适合对事务的完整性和并发性、数据的准确性要求比较高，增删操作多的应用。③Memory，所有的数据都保存在内存中，访问速度快，一旦服务关闭数据将丢失。适合更新不太频繁的数据量小的表用来快速得到访问结果。④Archive、Federated等。 Q2：索引是什么？ 答：MySQL官方对索引的定义为：索引（index）是帮助MySQL高效获取数据的数据结构（有序）。在数据之外，数据库系统还维护着满足特定查找算法的数据结构，这些数据结构以某种方式引用（指向）数据， 这样就可以在这些数据结构上实现高级查找算法，这种数据结构就是索引。 Q3：索引的优缺点有哪些？ 答：①优势：提高数据检索的效率，降低数据库的IO成本。通过索引列对数据进行排序，降低数据排序的成本，降低CPU的消耗。②劣势：实际上索引也是一张表，该表中保存了主键与索引字段，并指向实体类的记录，所以索引列也是要占用空间的。 虽然索引大大提高了查询效率，同时却也降低更新表的速度，如对表进行INSERT、UPDATE

面试的时候被面试官问到sql语句的性能优化，回来百度才发现我了解的那些真的是凤毛麟角，废话不多说，上干货： 1， 对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2，应尽量避免在 where 子句中对字段进行 null 值判断，创建表时NULL是默认值，但大多数时候应该使用NOT NULL，或者使用一个特殊的值，如0，-1作为默 认值。 3，应尽量避免在 where 子句中使用!=或<>操作符， MySQL只有对以下操作符才使用索引：<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE。 4，应尽量避免在 where 子句中使用 or 来连接条件， 否则将导致引擎放弃使用索引而进行全表扫描， 可以 使用UNION合并查询： select id from t where num=10 union all select id from t where num=20 5，in 和 not in 也要慎用，否则会导致全表扫描，对于连续的数值，能用 between 就不要用 in 了：Select id from t where num between 1 and 3 6，下面的查询也将导致全表扫描：select id from t where name like ‘%abc%’ 或者select id from t

今天我们用10分钟，重点梳理一遍以下几方面： 数据库知识点汇总； 数据库事务特性和隔离级别； 详解关系型数据库、索引与锁机制； 数据库调优与最佳实践； 面试考察点及加分项。 一、数据库的不同类型 1.常用的关系型数据库 Oracle：功能强大，主要缺点就是贵 MySQL：互联网行业中最流行的数据库，这不仅仅是因为MySQL的免费。可以说关系数据库场景中你需要的功能，MySQL都能很好的满足，后面详解部分会详细介绍MySQL的一些知识点 MariaDB：是MySQL的分支，由开源社区维护，MariaDB虽然被看作MySQL的替代品，但它在扩展功能、存储引擎上都有非常好的改进 PostgreSQL：也叫PGSQL，PGSQL类似于Oracle的多进程框架，可以支持高并发的应用场景，PG几乎支持所有的SQL标准，支持类型相当丰富。PG更加适合严格的企业应用场景，而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。 2.NoSQL数据库（非关系型数据库） Redis：提供了持久化能力，支持多种数据类型。Redis适用于数据变化快且数据大小可预测的场景。 MongoDB：一个基于分布式文件存储的数据库，将数据存储为一个文档，数据结构由键值对组成。MongoDB比较适合表结构不明确，且数据结构可能不断变化的场景，不适合有事务和复杂查询的场景。 HBase：建立在HDFS