mysql执行计划

一个问题引发的学习: mysql大表skip,limit访问尾部数据性能下降问题，对比结果如下 select * from big_table order by id asc LIMIT 5000000,5; /* Affected rows: 0 Found rows: 5 Warnings: 0 Duration for 1 query: 4.968 sec. */ select * from big_table a inner join (select id from big_table order by id ASC limit 5000000,5) b on a.id=b.id; /* Affected rows: 0 Found rows: 5 Warnings: 0 Duration for 1 query: 1.172 sec. */ 子查询方式，当排序方式为主键时，可以避免访问数据块，快速得到id； 这里回顾一下mysql基本数据结构 https://blog.csdn.net/caijunsen/article/details/83045985?depth_1-utm_source=distribute.pc_relevant.none-task&utm_source=distribute.pc_relevant.none-task 提高搜索效率，二叉排序树

开心一刻 　　楼主：来，我们先排练一遍 　　小伙伴们：好 　　嘿、哈、嚯 　　楼主：非常好，就是这个节奏，我们开始吧 　　楼主：啊、啊、啊，疼 ！ 你们是不是故意的 ？ 回表与覆盖索引 　　正式讲 ICP 之前了，我们先将相关的概念捋一捋，知道的就当回顾，不知道的就当了解了，这有助于对 ICP 的理解 　　建个示例表 tbl_index CREATE TABLE tbl_index ( c1 INT, c2 INT, c3 CHAR(1), PRIMARY KEY(c1), KEY idx_c2 (c2) ); 　　覆盖索引 　　　　如果 where 条件的列和 select 的列都在一个索引中，通过这个索引就可以完成查询，这就叫就叫覆盖索引；当然，覆盖索引基本针对的是组合索引（InnoDB 的聚簇索引有点特殊，具体可以看下面的图） 　　　　针对上面的 tbl_index， select c2 from tbl_index where c2 = 4 ; 是覆盖索引查询，但是这条 SQL 没有意义，如果我们在 tbl_index 表上增加索引 index idx_c2_c3 (c2,c3) ，那么 select c3 from tbl_index where c2 = 4 ; 走覆盖索引查询还是很有意义的，那问题又来了，覆盖索引的意义何在 ？ 我们往下看 　　回表 　　　

数据库层面 一：检查问题常用工具 1：msyqladmin：MySQL客户端，可进行管理操作 2：mysqlshow：功能强大的查看shell命令 3：show [SESSION | GLOBAL] variables：查看数据库参数信息 4：SHOW [SESSION | GLOBAL] STATUS：查看数据库的状态信息 5：information_schema：获取元数据的方法 6：SHOW ENGINE INNODB STATUS：Innodb引擎的所有状态 7：SHOW PROCESSLIST：查看当前所有连接session状态 8：explain：获取查询语句的执行计划 9：show index：查看表的索引信息 10：slow-log：记录慢查询语句 11：mysqldumpslow：分析slowlog文件的 二：解决思路 一般应急调优的思路：针对突然的业务办理卡顿，无法进行正常的业务处理，需要立马解决的场景 1：show processlist； 2：explain select id ,name from stu where name='clsn'; # ALL id name age sex； select id,name from stu where id=2-1 函数 结果集>30；show index from table； 3：通过执行计划判断，索引问题

查询优化、索引优化、库表结构优化需要齐头并进，一个不落，才能最终设计出在实际场景中能发挥良好效果的方案。 为什么查询速度会慢？ 如果把查询看作是一个任务，那么它由一系列子任务组成，每个子任务都会消耗一定的时间。如果要优化查询，实际上要优化其子任务，要么雄楚其中一些子任务，要么减少子任务的执行次数，要么让任务运行得更快。 如何优化数据访问？ 1、确认是否向数据库请求了不需要的数据 2、确认 MySQL 是否在扫描额外的记录 3、确认查询的方式，并予以合适的重构 当希望 MySQL 能够以更高的性能运行查询时，最好的办法就是弄清楚 MySQL 是如何优化和执行查询的。一旦理解这一点，很多查询优化工作实际上就是遵循一些原则让优化器能够按照预想的合理的方式运行。 那么，当 MySQL 执行一个查询时，MySQL 到底做了什么？ 1、客户端发送一条查询给服务器 2、服务器先检查查询缓存，如果命中了魂村，则立刻返回存储在魂村中的结果。否则进入下一阶段。 3、服务器端进行 SQL 解析、预处理，再由优化器生成对应的执行计划 4、MySQL 根据优化器生成的执行计划，条用存储引擎的 API 来执行查询 5、将结果返回给客户端 来源： https://www.cnblogs.com/stone94/p/12444491.html

背景介绍 最近在写SQL语句时，对选择IN 还是Exists 犹豫不决，于是把两种方法的SQL都写出来对比一下执行效率，发现IN的查询效率比Exists高了很多，于是想当然的认为IN的效率比Exists好，但本着寻根究底的原则，我想知道这个结论是否适用所有场景，以及为什么会出现这个结果。 网上查了一下相关资料，大体可以归纳为：外部表小，内部表大时，适用Exists；外部表大，内部表小时，适用IN。那我就困惑了，因为我的SQL语句里面，外表只有1W级别的数据，内表有30W级别的数据，按网上的说法应该是Exists的效率会比IN高的，但我的结果刚好相反！！ “没有调查就没有发言权”！于是我开始研究IN 和Exists的实际执行过程，从实践的角度出发，在根本上去寻找原因，于是有了这篇博文分享。 实验数据 我的实验数据包括两张表：t_author表 和 t_poetry表。 对应表的数据量： t_author表，13355条记录； t_poetry表，289917条记录。 对应的表结构如下： CREATE TABLE t_poetry ( id bigint(20) NOT NULL AUTO_INCREMENT, poetry_id bigint(20) NOT NULL COMMENT '诗词id', poetry_name varchar(200) NOT NULL COMMENT

一、前言 在当今的各种系统中，缓存是对系统性能优化的重要手段。MySQL Query Cache(MySQL查询缓存)在MySQL Server中是默认打开的，但是网上各种资料以及有经验的DBA都建议生产环境中把MySQL Query Cache关闭。按道理，MySQL Server默认打开，是鼓励用户使用缓存，但是大拿们却建议关闭此功能，并且国内各个云厂商提供的MySQL云服务中默认都是关闭这个功能，这是为什么？他们在使用中遇到了什么坑？本文将会从以下几方面来详解MySQL Query Cache。 1.MySQL查询缓存是什么？ MySQL缓存规则是什么？ 如何配置和缓存MySQL缓存 MySQL缓存的优缺点 生产要不要开启MySQL缓存 二、 MySQL查询缓存简介 MySQL查询缓存是MySQL中比较独特的一个缓存区域，用来缓存特定Query的整个结果集信息，且共享给所有客户端。为了提高完全相同的Query语句的响应速度，MySQL Server会对查询语句进行Hash计算后，把得到的hash值与Query查询的结果集对应存放在Query Cache中。当MySQL Server打开Query Cache之后，MySQL Server会对接收到的每一个SELECT 语句通过特定的Hash算法计算该Query的Hash值，然后通过该hashi值到Query Cache中去匹配

1.存储过程简介 　　常用的SQL语句在执行的时候需要要先编译后执行，而存储过程是一组为了完成特定功能的SQL语句集，经编译后存储在数据库中，用户通过指定存储过程的名字并给定参数（如果该存储过程带有参数）来调用执行它。类似于java中的api方法，先定义好，再通过相关的引用调用这个api方法。　　 　　存储过程通常有以下优点： (1).存储过程增强了SQL语言的功能和灵活性。存储过程可以用流控制语句编写，有很强的灵活性，可以完成复杂的判断和较复杂的运算。 (2).存储过程允许标准组件是编程。存储过程被创建后，可以在程序中被多次调用，而不必重新编写该存储过程的SQL语句。而且数据库专业人员可以随时对存储过程进行修改，对应用程序源代码毫无影响。 (3).存储过程能实现较快的执行速度。如果某一操作包含大量的Transaction-SQL代码或分别被多次执行，那么存储过程要比批处理的执行速度快很多。因为存储过程是预编译的。在首次运行一个存储过程时查询，优化器对其进行分析优化，并且给出最终被存储在系统表中的执行计划。而批处理的Transaction-SQL语句在每次运行时都要进行编译和优化，速度相对要慢一些。 (4).存储过程能过减少网络流量。针对同一个数据库对象的操作（如查询、修改），如果这一操作所涉及的Transaction-SQL语句被组织程存储过程

MySql（五）SQL优化-优化SQL语句的一般步骤 一、优化SQL语句的一般步骤 1.1 通过show status命令了解各种SQL的执行频率 1.2 定位执行效率较低的SQL语句 1.3 通过explain分析低效sql的执行计划 1.4 通过show profile分析sql 1.5 通过trace分析优化器如何选择执行计划 1.6 确定问题并采取相应的优化措施 一、优化SQL语句的一般步骤 1.1 通过show status命令了解各种SQL的执行频率 Mysql客户端连接成功后，通过 show [ session | global ] status 命令可以提供服务器状态信息。 show [session|global] status 可以根据需要加上参数"session"或者"global"来显示seesion级（当前连接）的统计结果和global级（自数据库上次启动至今）的统计结果。如果不写，默认使用的参数时"session"。 例如：显示当前session中所有统计参数的值： mysql > show status like 'Com_%' ; Com_xxx表示每个xxx语句执行的次数。 Com_select：执行select操作的次数，一次查询之累加1. Com_insert：执行insert操作的次数，对于批量插入insert操作，只累加一次。 Com

文章目录 索引 索引原理 索引技巧与注意事项 建立索引的原则 利用索引排序 InnoDB索引模型 联合索引 聚集索引 辅助索引 覆盖索引 索引合并 Cardinality（基数） 查看索引 Cardinality 优化器选择不使用索引的情况 MRR 验证MRR ICP 验证ICP 索引 只有当索引帮助存储引擎快速查找到记录的带来的好处大于其带来的额外工作时，索引才是有效的。对于非常小的表，大部分情况下简单的全表扫描更高效 在一个100w条数据的表中，如果某一列没有添加索引，那么每一句select语句都要随机地逐条扫描100w行数据，每次都要从中寻找0或者更多匹配的行。虽然这些数据最初是按照顺序加载的，但sql也不能理解这种顺序，它必须要处理所有行才能找到匹配的数据。添加索引并不总能自动改善所有类型的SQL查询的性能。有时候执行全表扫描反而更加高效，这取决于所要求的行数。这就是两种不同访问方式的差异，即通过随机IO操作来获取个别行的数据和使用查询索引及有序IO操作来读取所有数据。 索引除了在给定表上限制需要读取的数据外，索引的另一个主要用途就是快捷高效地在相关的表之间做Join操作。在需要Join的列上使用索引可以显著提升性能，并可以在另一个表中快速找到一个匹配的值。 优点 索引大大减少了服务器需要扫描的数据量 索引可以帮助服务器避免排序和临时表 索引可以将随机IO变为顺序IO

索引目的 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者w开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？ 索引原理 除了词典，生活中随处可见索引的例子，如火车站的车次表、图书的目录等。它们的原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂许多，因为不仅面临着等值查询，还有范围查询(>、<、between、in)、模糊查询(like)、并集查询(or)等等。数据库应该选择怎么样的方式来应对所有的问题呢？我们回想字典的例子，能不能把数据分成段，然后分段查询呢？最简单的如果1000条数据，1到100分成第一段，101到200分成第二段，201到300分成第三段……这样查第250条数据，只要找第三段就可以了，一下子去除了90%的无效数据。但如果是1千万的记录呢，分成几段比较好？稍有算法基础的同学会想到搜索树，其平均复杂度是lgN，具有不错的查询性能。但这里我们忽略了一个关键的问题，复杂度模型是基于每次相同的操作成本来考虑的，数据库实现比较复杂，数据保存在磁盘上