mysql执行计划

阅读目录(Content) 数据库命令规范 数据库基本设计规范 1. 所有表必须使用Innodb存储引擎 2. 数据库和表的字符集统一使用UTF8 3. 所有表和字段都需要添加注释 4. 尽量控制单表数据量的大小，建议控制在500万以内 5. 谨慎使用Mysql分区表 6. 尽量做到冷热数据分离，减小表的宽度 7. 禁止在表中建立预留字段 8. 禁止在数据库中存储图片，文件等大的二进制数据 9. 禁止在线上做数据库压力测试 10. 禁止从开发环境，测试环境直接连接生成环境数据库 数据库字段设计规范 1. 优先选择符合存储需要的最小的数据类型 2. 避免使用TEXT、BLOB数据类型，最常见的TEXT类型可以存储64k的数据 3. 避免使用ENUM类型 4. 尽可能把所有列定义为NOT NULL 5. 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间 6. 同财务相关的金额类数据必须使用decimal类型 索引设计规范 1. 限制每张表上的索引数量，建议单张表索引不超过5个 2. 禁止给表中的每一列都建立单独的索引 3. 每个Innodb表必须有个主键 常见索引列建议 如何选择索引列的顺序 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间） 对于频繁的查询优先考虑使用覆盖索引 索引SET规范 尽量避免使用外键约束 数据库SQL开发规范 1.

mysql查询的过程图 为什么要优化 系统的吞吐量瓶颈往往出现在数据库的访问速度上 随着应用程序的运行，数据库的中的数据会越来越多，处理时间会相应变慢 数据是存放在磁盘上的，读写速度无法和内存相比 如何优化 设计数据库时：数据库表、字段的设计，存储引擎 利用好MySQL自身提供的功能，如索引等 横向扩展：MySQL集群、负载均衡、读写分离 SQL语句的优化（收效甚微） 一、字段设计阶段 选取最适用的字段属性 1. 字段的宽度设得尽可能小 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。 2. 尽量把字段设置为NOTNULL 在可能的情况下，应该尽量把字段设置为NOTNULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 3. 确定数据定义为ENUM类型 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 4. 单表字段不宜过多，可以预留字段 满足业务需求的前提下二三是个字段就是极限了，可以预留字段便于扩展。 遵循数据表的设计规范 1. 第一范式(1NF) 字段值具有原子性

目的 数据库中很重要的设计一部分，莫过于索引了。 B+树索引是 MySQL中设计的索引。B+树索引是基于B+树基础发展而来的。 然而，在理解了B+树索引结构以后，对优化SQL会事 半 功 倍 。还针对前面 MySQL索引选择规则 文章做进一步分析。 1：B+树 与 B+树索引 区别 B+树 B+树索引 存储位置 内存 磁盘 扇出率 低 高 并发控制 可以不考虑 需要考虑 分裂方向 不需要考虑 向左、向右 上图中列出两者的区别，光看图片可能不能理解每个区别对应的含义。 下面就来分析一下重要的区别： 1.1：存储位置： B+树 是为磁盘或其他直接存取辅助设备而设计的一种平衡查找树，因此主要操作是计算不需要文件来存储，也就是在内存来操作的。 B+树索引 是基于磁盘，因此数据库会出现索引文件，索引文件就是存储在磁盘上的。 1.2：分裂方向 B+树 是内存结构，不需要考虑页分裂的方向。 B+树索引 在磁盘上，为了充分利用磁盘的顺序特性，还需要根据不同插入情况考虑不同的分裂点记录以及分裂的方向。 2：MySQL的InnoDB存储引擎的索引设计 InnoDB存储引擎将B+树索引分为聚集索引和辅助索引。 聚集索引是通过将表的主键作为键值来构造B+树。如果没有显示创建，自动创建一个6字节的主键。聚集索引还包含记录所有列信息。 2.1：存储结构 聚集索引的非叶子点存放的是<键值， 地址>

原文链接： http://blog.csdn.net/soonfly/article/details/70238902 锁是计算机协调多个进程或线程并发访问某一资源的机制。在数据库中，除传统的 计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一 个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。本章我们着重讨论MySQL锁机制 的特点，常见的锁问题，以及解决MySQL锁问题的一些方法或建议。 Mysql用到了很多这种锁机制，比如行锁，表锁等，读锁，写锁等，都是在做操作之前先上锁。这些锁统称为悲观锁(Pessimistic Lock)。 MySQL锁概述 相对其他数据库而言，MySQL的锁机制比较简单，其最 显著的特点是不同的存储引擎支持不同的锁机制。比如，MyISAM和MEMORY存储引擎采用的是表级锁（table-level locking）；BDB存储引擎采用的是页面锁（page-level locking），但也支持表级锁；InnoDB存储引擎既支持行级锁（row-level locking），也支持表级锁，但默认情况下是采用行级锁。 表级锁：开销小，加锁快；不会出现死锁；锁定粒度大，发生锁冲突的概率最高，并发度最低。

目录 一、执行计划概念 二、Explain用法 三、Explain属性介绍 3.1 id属性 3.2 select_type属性 3.3 table属性 3.4 type属性 3.5 possible_keys属性 3.6 key属性 3.7 key_len属性 3.8 ref属性 3.9 rows属性 3.10 Extra属性 继上一篇博客 《MySQL的索引知识学习笔记》 之后，我再记录一篇MySQL执行计划方面的博客，本博客是我在学习尚硅谷的学习教程后，做的笔记，当然我不是为了所谓宣传，仅仅是学习记录的笔记。本来可以不分享出来，不过，分享出来的笔记不仅可以给网上的学习者参考学习，同时写在csdn比较方便，可以支持图片上传，也方便自己以后查找复习 附录：我创建的数据库方面的专栏 SQL调优方面的专栏 MySQL知识方面的专栏 @ 一、执行计划概念 执行计划(Explain)：explain显示了mysql如何使用索引来处理select语句以及连接表，使用Explain关键字可以模拟MySQL优化器执行SQL查询语句，从而知道MySQL是如何处理SQL语句的。所以执行计划常用于SQL调优 二、Explain用法 Explain的用法： Explain + SQL语句 mysql> explain select * from sys_user; mysql> use

如今随着互联网的发展，数据的量级也是撑指数的增长，从GB到TB到PB。对数据的各种操作也是愈加的困难，传统的关系性数据库已经无法满足快速查询与插入数据的需求。这个时候NoSQL的出现暂时解决了这一危机。它通过降低数据的安全性，减少对事务的支持，减少对复杂查询的支持，来获取性能上的提升。但是，在有些场合NoSQL一些折衷是无法满足使用场景的，就比如有些使用场景是绝对要有事务与安全指标的。这个时候NoSQL肯定是无法满足的，所以还是需要使用关系性数据库。 虽然关系型数据库在海量数据中逊色于NoSQL数据库，但是如果你操作正确，它的性能还是会满足你的需求的。针对数据的不同操作，其优化方向也是不尽相同。对于数据移植，查询和插入等操作，可以从不同的方向去考虑。而在优化的时候还需要考虑其他相关操作是否会产生影响。就比如你可以通过创建索引提高查询性能，但是这会导致插入数据的时候因为要建立更新索引导致插入性能降低，你是否可以接受这一降低那。所以，对数据库的优化是要考虑多个方向，寻找一个折衷的最佳方案。 一：查询优化 1：创建索引。 最简单也是最常用的优化就是查询。因为对于CRUD操作，read操作是占据了绝大部分的比例，所以read的性能基本上决定了应用的性能。对于查询性能最常用的就是创建索引。经过测试，2000万条记录，每条记录200字节两列varchar类型的

问题 索引可以加快查询速度，那么是不是表都需要建立索引呢？ MySQL 索引选择原则分析（一） 中已经介绍了，索引文件是存储在磁盘上的。 因此索引虽然加快了查询速度，但是索引也是有代价的。 一、表记录比较少时，没必要建立索引。 二、索引的选择性比较低时，没必要建立索引。 索引的选择性是指不重复的索引值与表记录数的比值。 索引的选择性的取值范围为（0,1】，选择性越高的索引价值越大。 如：MySQL示例库的titles表，看一下它的选择性： SELECT COUNT(DISTINCT(title))/COUNT(1) AS Selectivity FROM titles; title的选择性为0.0000，所以没有必要为其单独建索引。 三、前缀索引 前缀索引是用列的前缀代替整个列作为索引key，当前缀长度合适时，可以做到既使得前缀索引的选择性接近全列索引，同时因为索引key变短而减少了索引文件的大小和维护开销。 下面以employees表为例介绍前缀索引的选择和使用。 SELECT * FROM employees WHERE first_name='Eric' AND last_name='Anido'; 执行上面的SQL，时间为0.235s。 上面的SQL查询查询计划，可以看出，type为ALL，也就是全表扫描。 建<first_name>或<first_name,last

什么是索引？ 1、索引 索引是表的目录，在查找内容之前可以先在目录中查找索引位置，以此快速定位查询数据。对于索引，会保存在额外的文件中。 2、 索引，是数据库中专门用于帮助用户快速查询数据的一种数据结构。类似于字典中的目录，查找字典内容时可以根据目录查找到数据的存放位置，然后直接获取即可。 索引由数据库中一列或多列组合而成，其作用是提高对表中数据的查询速度 索引的优点是可以提高检索数据的速度 索引的缺点是创建和维护索引需要耗费时间 索引可以提高查询速度，会减慢写入速度 索引分类 1.普通索引 2.唯一索引 3.全文索引 4.单列索引 5.多列索引 6.空间索引 7.主键索引 8.组合索引 普通索引：仅加速查询 唯一索引：加速查询 + 列值唯一（可以有null） 主键索引：加速查询 + 列值唯一 +　表中只有一个（不可以有null） 组合索引：多列值组成一个索引， 专门用于组合搜索，其效率大于索引合并 全文索引：对文本的内容进行分词，进行搜索 索引合并，使用多个单列索引组合搜索 覆盖索引，select的数据列只用从索引中就能够取得，不必读取数据行，换句话说查询列要被所建的索引覆盖 如何创建索引？记住一个单词—explain 创建表的时候创建索引 CREATE TABLE tbl_name( 字段名称 字段类型 [完整性约束条件]， ，，，, [UNIQUE|FULLTEXT

索引相关 关于MySQL的索引,曾经进行过一次总结,文章链接在这里 Mysql索引原理及其优化. 1. 什么是索引? 索引是一种数据结构,可以帮助我们快速的进行数据的查找. 2. 索引是个什么样的数据结构呢? 索引的数据结构和具体存储引擎的实现有关, 在MySQL中使用较多的索引有Hash索引,B+树索引等,而我们经常使用的InnoDB存储引擎的默认索引实现为:B+树索引. 3. Hash索引和B+树所有有什么区别或者说优劣呢? 首先要知道Hash索引和B+树索引的底层实现原理: hash索引底层就是hash表,进行查找时,调用一次hash函数就可以获取到相应的键值,之后进行回表查询获得实际数据. B+树底层实现是多路平衡查找树 .对于每一次的查询都是从根节点出发,查找到叶子节点方可以获得所查键值,然后根据查询判断是否需要回表查询数据. 那么可以看出他们有以下的不同: hash索引进行等值查询更快(一般情况下),但是却 无法进行范围查询 . 因为在hash索引中经过hash函数建立索引之后,索引的顺序与原顺序无法保持一致,不能支持范围查询.而B+树的的所有节点皆遵循(左节点小于父节点,右节点大于父节点,多叉树也类似),天然支持范围. hash索引不支持使用索引进行排序 ,原理同上. hash索引不支持模糊查询 以及多列索引的最左前缀匹配.原理也是因为hash函数的不可预测

在解析一个查询语句前，如果查询缓存是打开的，那么mysql会检查这个查询语句是否命中查询缓存中的数据。如果当前查询恰好命中查询缓存，在检查一次用户权限后直接返回缓存中的结果。这种情况下，查询不会被解析，也不会生成执行计划，更不会执行。 mysql将缓存存放在一个引用表（不要理解成 table ，可以认为是类似于 HashMap 的数据结构），通过一个哈希值索引，这个哈希值通过查询本身、当前要查询的数据库、客户端协议版本号等一些可能影响结果的信息计算得来。所以两个查询在任何字符上的不同（例如：空格、注释），都会导致缓存不会命中。 如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、mysql库中的系统表，其查询结果都不会被缓存。比如函数 NOW() 或者 CURRENT_DATE() 会因为不同的查询时间，返回不同的查询结果，再比如包含 CURRENT_USER 或者 CONNECION_ID() 的查询语句会因为不同的用户而返回不同的结果，将这样的查询结果缓存起来没有任何的意义。 既然是缓存，就会失效，那查询缓存何时失效呢？mysql的查询缓存系统会跟踪查询中涉及的每个表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。正因为如此，在任何的写操作时，MySQL必须将对应表的所有缓存都设置为失效。如果查询缓存非常大或者碎片很多