mysql执行计划

很多数据库产品都能够缓存查询的执行计划，对于相同类型的SQL就可以跳过SQL解析和执行计划生成截断。MySQL在某些场景下也可以实现，但是MySQL还有另一种不同的缓存类型：缓存完整的select查询结果，也就是查询缓存。 MySQL查询缓存保存查询返回的完整结果。当查询命中该缓存，MySQL会like返回结果，跳过了解析、优化和执行截断。 查询缓存系统会跟踪查询中涉及的每个表，如果这些表发生变化，那么和这个表相关的所有的缓存数据都将失效。这种机制效率看起来比较低，因为数据表变化时很有可能对应的查询结果没有变更，但是这种简单实现代价很小，而这点对于一个非常繁忙的系统来说非常重要。 查询缓存对应用程序是完全透明的。应用程序无需关心MySQL是通过查询返回的还是实际执行返回的结果。事实上，这两种方式执行的结果是完全相同的。换句话说，查询缓存无需使用任何语法。无论是MySQL开启或关闭查询缓存，对程序都是透明的。 随着现在的通用服务器越来越强大，查询缓存被发现是一个影响服务器扩展性的因素。它可能成为整个服务器的资源竞争单点，在多核服务器上还可能导致服务器僵死。所以大部分时候应该默认关闭查询缓存，如果查询缓存作用很大的话，可以配置个几十兆的小缓存空间。 1 MySQL如何判断缓存命中 MySQL判断缓存命中的方法很简单：缓存存放在一个引用表中，通过一个哈希值引用，这个哈希值包括了如下因素：

Mysql 索引 A 、索引的基本操作 1 、概念 1 ）、查看索引 show index from 数据库表名 2 ）、 alter table 数据库表 add index 索引名称 ( 数据库表字段名称 ) 2 、索引类型： 1 ）、 PRIMARY KEY （主键索引） ALTER TABLE table_name ADD PRIMARY KEY ( column ) 2 ）、 UNIQUE( 唯一索引 ) ALTER TABLE table_name ADD UNIQUE (column) 3 ）、 INDEX( 普通索引 ) ALTER TABLE table_name ADD INDEX index_name ( column ) 4 ）、 FULLTEXT( 全文索引 ) ALTER TABLE table_name ADD FULLTEXT ( column ) 5 ）、多列索引 ALTER TABLE table_name ADD INDEX index_name ( column1, column2, column3 ) 3 、操作 1). 普通索引。 这是最基本的索引，它没有任何限制。它有以下几种创建方式： （ 1 ）创建索引： CREATE INDEX indexName ON tableName(tableColumns(length)); 如果是

OR、in和union all 查询效率到底哪个快。 网上很多的声音都是说union all 快于 or、in，因为or、in会导致全表扫描，他们给出了很多的实例。 但真的union all真的快于or、in？本文就是采用实际的实例来探讨到底是它们之间的效率。 1：创建表，插入数据、数据量为1千万【要不效果不明显】。 Sql代码 drop table if EXISTS BT; create table BT( ID int (10) NOT NUll , VName varchar (20) DEFAULT '' NOT NULL , PRIMARY key ( ID ) )ENGINE=INNODB; 该表只有两个字段 ID为主键【索引页类似】，一个是普通的字段。（偷懒就用简单的表结构呢） 向BT表中插入1千万条数据 这里我写了一个简单的存储过程【所以你的mysql版本至少大于5.0，俺的版本为5.1】，代码如下。 注意：最好 INSERT INTO BT ( ID,VNAME ) VALUES( i, CONCAT( 'M', i ) );---1 修改为 INSERT INTO BT ( ID,VNAME ) VALUES( i, CONCAT( 'M', i, 'TT' ) );---2 修改原因在 非索引列及VNAME使用了联合进行完全扫描请使用1 。

各属性含义： id ：查询的序列号 select_type ：查询的类型，主要是区别普通查询和联合查询、子查询之类的复杂查询 SIMPLE：查询中不包含子查询或者UNION 查询中若包含任何复杂的子部分，最外层查询则被标记为：PRIMARY 在SELECT或WHERE列表中包含了子查询，该子查询被标记为：SUBQUERY table ：输出的行所引用的表 type ：访问类型 从左至右，性能由差到好 ALL：扫描全表 index：扫描全部索引树 range：扫描部分索引，索引范围扫描，对索引的扫描开始于某一点，返回匹配值域的行，常见于between、<、>等的查询 ref：使用非唯一索引或非唯一索引前缀进行的查找 （eq_ref和const的区别：） eq_ref：唯一性索引扫描，对于每个索引键，表中只有一条记录与之匹配。常见于主键或唯一索引扫描 const：单表中最多有一个匹配行，查询起来非常迅速，例如根据主键或唯一索引查询。 system：system是const类型的特例，当查询的表只有一行的情况下， 使用system。 NULL：不用访问表或者索引，直接就能得到结果，如select 1 from test where 1 possible_keys ：表示查询时可能使用的索引。如果是空的，没有相关的索引。这时要提高性能，可通过检验WHERE子句，看是否引用某些字段

using filesort 一般出现在 使用了 order by 语句当中。 using filesort不一定引起mysql的性能问题。但是如果查询次数非常多，那么每次在mysql中进行排序，还是会有影响的。 这里的优化方式是在order by 的字段建立索引，例如 语句： SELECT * FROM yw_syjgb ORDER BY result_date desc LIMIT 0,1000; 查看执行计划： +----+-------------+----------+------+---------------+------+---------+------+---------+----------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+---------+----------------+ | 1 | SIMPLE | yw_syjgb | ALL | NULL | NULL | NULL | NULL | 1312418 | Using filesort | +

为了优化SQL语句的排序性能，最好的情况是避免排序，合理利用索引是一个不错的方法。因为索引本身也是有序的，如果在需要排序的字段上面建立了合适的索引，那么就可以跳过排序的过程，提高SQL的查询速度。下面我通过一些典型的SQL来说明哪些SQL可以利用索引减少排序，哪些SQL不能。假设t1表存在索引key1(key_part1,key_part2),key2(key2) a.可以利用索引避免排序的SQL 1 2 3 4 SELECT * FROM t1 ORDER BY key_part1,key_part2; SELECT * FROM t1 WHERE key_part1 = constant ORDER BY key_part2; SELECT * FROM t1 WHERE key_part1 > constant ORDER BY key_part1 ASC ; SELECT * FROM t1 WHERE key_part1 = constant1 AND key_part2 > constant2 ORDER BY key_part2; b.不能利用索引避免排序的SQL 1 2 3 4 5 6 7 8 9 10 11 //排序字段在多个索引中，无法使用索引排序 SELECT * FROM t1 ORDER BY key_part1,key_part2, key2; /

在一些情况下，MySQL可以直接使用索引来满足一个 ORDER BY 或 GROUP BY 子句而无需做额外的排序。尽管 ORDER BY 不是和索引的顺序准确匹配，索引还是可以被用到，只要不用的索引部分和所有的额外的 ORDER BY 字段在 WHERE 子句中都被包括了。 使用索引的MySQL Order By 下列的几个查询都会使用索引来解决 ORDER BY 或 GROUP BY 部分： SELECT * FROM t1 ORDER BY key_part1,key_part2,... ; SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2; SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2; SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 DESC; SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC, key_part2 DESC; 不使用索引的MySQL Order By 在另一些情况下，MySQL无法使用索引来满足 ORDER BY，尽管它会使用索引来找到记录来匹配 WHERE 子句。这些情况如下： *

背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。 在MVCC并发控制中，读操作可以分成两类：快照读 (snapshot read)与当前读

转载自何登成的技术博客：http://hedengcheng.com/?p=771 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎，实现的是基于多版本的并发控制协议——MVCC ( Multi-Version Concurrency Control ) (注：与MVCC相对的，是基于锁的并发控制，Lock-Based Concurrency Control)。MVCC最大的好处，相信也是耳熟能详：读不加锁，读写不冲突。在读多写少的OLTP应用中，读写不冲突是非常重要的，极大的增加了系统的并发性能，这也是为什么现阶段，几乎所有的RDBMS，都支持了MVCC。

http://hedengcheng.com/?p=771 类似的文章：https://www.cnblogs.com/yelbosh/p/5813865.html 1.解释了为什么update insert delete 也属于当前读 2.分9种情况解释了rc rr级别下，当前读在mysql中是如何加锁的 2.1 select no update or share mode 操作在非seariable下均不加锁，采用的是快照读，mysql使用mvcc返回历史数据 2.2 对于当前读，分情况讨论 背景 MySQL/InnoDB的加锁分析，一直是一个比较困难的话题。我在工作过程中，经常会有同事咨询这方面的问题。同时，微博上也经常会收到MySQL锁相关的私信，让我帮助解决一些死锁的问题。本文，准备就MySQL/InnoDB的加锁问题，展开较为深入的分析与讨论，主要是介绍一种思路，运用此思路，拿到任何一条SQL语句，都能完整的分析出这条语句会加什么锁？会有什么样的使用风险？甚至是分析线上的一个死锁场景，了解死锁产生的原因。 注： MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍，都是基于InnoDB存储引擎，其他引擎的表现，会有较大的区别。 MVCC：Snapshot Read vs Current Read MySQL InnoDB存储引擎