mysql索引

为什么要使用索引？ 什么是索引？ MySQL 官方对索引的定义为：索引（Index）是帮助 MySQL 高效获取数据的数据结构。 　　影响数据库效率的原因千千万万，使用索引是为了解决哪方面的数据库的瓶颈？ 点一 MySQL 数据库存储数据最终是以文件的形式存储到硬盘的。一般来说，我们在程序中使用的时候肯定要把磁盘文件中的数据读到内存中。那么就这个 “读” 的过程是什么样子的呢？磁盘读取数据靠的是机械运动，每次读取数据花费的时间可以分为寻道时间、旋转延迟、传输时间三个部分，寻道时间指的是磁臂移动到指定磁道所需要的时间，主流磁盘的寻道时间一般在5ms以下；旋转延迟就是我们经常听说的磁盘转速，比如一个磁盘7200转，表示每分钟能转7200次，也就是说1秒钟能转120次，旋转延迟就是1/120/2 = 4.17ms（旋转延迟等于磁盘转动半圈时间）；传输时间指的是从磁盘读出或将数据写入磁盘的时间，一般在零点几毫秒，相对于前两个时间可以忽略不计。那么访问一次磁盘的时间，即一次磁盘IO的时间约等于5+4.17 = 9ms左右，听起来还挺不错的，但要知道一台 500 - MIPS 的机器每秒可以执行5亿条指令，因为指令依靠的是电的性质，换句话说执行一次IO的时间可以执行40万条指令（如果以 CPU 的指令执行效率来比较的话），数据库动辄十万百万乃至千万级数据，每次9毫秒的时间，显然是个灾难

有时候我们会发现mysql可能出现选错索引的情况，要了解这个问题我们得先看看sql优化器是怎么选择索引的 索引选择逻辑 优化器选择索引的目的，是找到一个最优的执行方案，并用最小的代价去执行语句。在数据库里面，扫描行数是影响执行代价的因素之一。扫描的行数越少，意味着访问磁盘数据的次数越少，消耗的 CPU 资源越少 扫描行数是怎么判断的? MySQL 在真正开始执行语句之前，并不能精确地知道满足这个条件的记录有多少条，而只能根据统计信息来估算记录数 这个统计信息就是索引的“区分度”。显然，一个索引上不同的值越多，这个索引的区分度就越好。而一个索引上不同的值的个数，我们称之为“基数”。也就是说，这个基数越大，索引的区分度越好 MySQL 是怎样得到索引的基数的呢 采样统计的时候，InnoDB 默认会选择 N 个数据页，统计这些页面上的不同值，得到一个平均值，然后乘以这个索引的页面数，就得到了这个索引的基数 而数据表是会持续更新的，索引统计信息也不会固定不变。所以，当变更的数据行数超过 1/M 的时候，会自动触发重新做一次索引统计 在 MySQL 中，有两种存储索引统计的方式，可以通过设置参数 innodb_stats_persistent 的值来选择: 设置为 on 的时候，表示统计信息会持久化存储。这时，默认的 N 是 20，M 是 10。 设置为 off 的时候

本文出处： http://www.cnblogs.com/wy123/p/7374078.html （保留出处并非什么原创作品权利，本人拙作还远远达不到，仅仅是为了链接到原文，因为后续对可能存在的一些错误进行修正或补充，无他） ICP优化原理 Index Condition Pushdown (ICP)，也称为索引条件下推，体现在执行计划的上是会出现Using index condition（Extra列，当然Extra列的信息太多了，只能做简单分析） ICP原理通俗讲就是，查询过程中，直接在查询引擎层的API获取数据的时候实现"非直接索引"过滤条件的筛选，而不是查询引擎层查询出来之后在Server层筛选。 换句话说就是ICP在获取数据的同时实现了where的次选条件中无法直接使用索引的情况下的筛选，避免了没有ICP优化的时候分两个步骤的实现（获取数据的过程没有做次选条件的过滤） 如果是非ICP优化查询的话，是两步，第一步是获取数据，第二步是获取的数据进行条件筛选。 显然，相比后者，前者可以一步实现索引的查找Seek+filter，效率上更高。 适应的场景： ICP的优化策略可用于range、ref、eq_ref、ref_or_null 类型的访问数据方法 其实没有实例不太好理解这种优化策略，还是举两个实际列子吧。 ICP优化实例 第一个例子在网上非常多，也非常容易理解

ICP技术是在MySQL5.6中引入的一种索引优化技术。它能减少在使用 二级索引 过滤where条件时的回表次数 和 减少MySQL server层和引擎层的交互次数。在索引组织表中，使用二级索引进行回表的代价相比堆表中是要高一些的。相关文档地址：http://dev.mysql.com/doc/refman/5.6/en/index-condition-pushdown-optimization.html Index Condition Pushdown optimization is used for the range , ref , eq_ref , and ref_or_null access methods when there is a need to access full table rows. This strategy can be used for InnoDB and MyISAM tables. (Note that index condition pushdown is not supported with partitioned tables in MySQL 5.6 ; this issue is resolved in MySQL 5.7.) For InnoDB tables, however, ICP is used only for

常见的数据库面试题有哪些 （一）什么是存储过程？有哪些优缺点？ 存储过程是一些预编译的SQL语句。 更加直白的理解：存储过程可以说是一个记录集，它是由一些T-SQL语句组成的代码块，这些T-SQL语句代码像一个方法一样实现一些功能（对单表或多表的增删改查），然后再给这个代码块取一个名字，在用到这个功能的时候调用他就行了。 存储过程是一个预编译的代码块，执行效率比较高 一个存储过程替代大量T_SQL语句 ，可以降低网络通信量，提高通信速率 可以一定程度上确保数据安全 （二）索引是什么？有什么作用以及优缺点？ 索引是对数据库表中一或多个列的值进行排序的结构，是帮助MySQL高效获取数据的数据结构 你也可以这样理解：索引就是加快检索表中数据的方法。数据库的索引类似于书籍的索引。在书籍中，索引允许用户不必翻阅完整个书就能迅速地找到所需要的信息。在数据库中，索引也允许数据库程序迅速地找到表中的数据，而不必扫描整个数据库。 MySQL 数据库几个基本的索引类型：普通索引、唯一索引、主键索引、全文索引 索引加快数据库的检索速度 索引降低了插入、删除、修改等维护任务的速度 唯一索引可以确保每一行数据的唯一性 通过使用索引，可以在查询的过程中使用优化隐藏器，提高系统的性能 索引需要占物理和数据空间 （三）什么是事务？ 事务（Transaction）是并发控制的基本单位。所谓的事务，它是一个操作序列

原文链接 大家有没有遇到过慢查询的情况，执行一条SQL需要几秒，甚至十几、几十秒的时间，这时候DBA就会建议你去把查询的 SQL 优化一下，怎么优化？你能想到的就是加索引吧？ 为什么加索引就查的快了？这就要从索引的本质以及他的底层原理说起。 索引是什么 那索引到底是什么呢?你是不是还停留在大学学『数据库原理』时老师讲的“索引就像字典的目录”这样的概念？老师讲的没错，但没有深入去讲。 其实索引就是一种用于快速查找数据的数据结构，是帮助MySQL高效获取数据的排好序的数据结构。 索引的好处 举例说明索引的好处以及是怎么加快查询的。 假设我们有一个表t，它有俩字段，Col1和Col2，如下： 不加索引 不加索引的情况下，SQL： select * from t where t.col2=89 ，需要从表的第一行一行行遍历比对col2的值是否等于89，这样需要比对6次才能查到。这只是只有几行记录的表，那如果是百万级千万级的表呢？是不是就比较的次数就更多了，那还不得慢死。 加索引 如果col2这列加了索引，mysql内部会维护一个数据结构。假设mysql用的数据结构是红黑树（右子树的元素大于根节点，左子树的元素小于根节点）的数据结构建立索引，那就像上图右边那样。这样的话，刚才的那条SQL是不是只需要2次磁盘IO就查到了，是不是快很多了。 这就是索引的好处。索引使用比较巧妙的数据结构

军规适用场景：并发量大、数据量大的互联网业务 军规：介绍内容 解读：讲解原因，解读比军规更重要 一、基础规范 （1）必须使用 InnoDB 存储引擎 解读：支持事务、行级锁、并发性能更好、CPU 及内存缓存页优化使得资源利用率更高 （2）必须使用 UTF8 字符集 解读：万国码，无需转码，无乱码风险，节省空间 （3）数据表、数据字段必须加入中文注释 解读：N 年后谁 tm 知道这个 r1,r2,r3 字段是干嘛的 （4）禁止使用存储过程、视图、触发器、Event 解读：高并发大数据的互联网业务，架构设计思路是“解放数据库 CPU，将计算转移到服务层”，并发量大的情况下，这些功能很可能将数据库拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU 计算还是上移吧 （5）禁止存储大文件或者大照片 解读：为何要让数据库做它不擅长的事情？大文件和照片存储在文件系统，数据库里存 URI 多好 二、命名规范 （6）只允许使用内网域名，而不是 ip 连接数据库 （7）线上环境、开发环境、测试环境数据库内网域名遵循命名规范 业务名称：xxx 线上环境：dj.xxx.db 开发环境：dj.xxx.rdb 测试环境：dj.xxx.tdb 从库在名称后加-s 标识，备库在名称后加-ss 标识 线上从库：dj.xxx-s.db 线上备库：dj.xxx-sss

最近一段时间都学习mysql，将重要的知识点总结如下： 一、字段、表、索引设计规范相关 二、事务相关 三、锁相关 四、存储引擎相关 五、大表优化相关 六、索引优化相关 七、语句优化相关 一、字段、表、索引设计规范 1、字段设计规范 ① 字段类型优先选择符合存储需要的最小类型 字段类型优先级：整型>date;time >enum>char;varchar>blob 原因：整型，time运算快，节省内存；enum列内部是用整型存储的，char，varchar要考虑字符集的转换和排序的校对集，速度慢；blob无法使用临时表。 ② 够用就行（如smallint，varchar(N)） 原因：大的字段浪费内存，影响速度，如varchar(10),varchar(300),虽然存储的内容一样，但是,在表联查时，varchar(300)要花更多内存 ③ 尽量避免使用允许为null() 原因：null不利于索引，要用特殊的字节标注，在磁盘上占的空间其实更大 例子：建两个相同字段的表，一个允许为null，一个不允许。可以发现为null的索引更大些。 ④ 避免使用ENUM类型 修改ENUM值需要使用ALTER语句 ENUM类型的ORDER BY操作效率低，需要额外操作 禁止使用数值作为ENUM的枚举值 ⑤ 使用TIMESTAMP（4个字节）或DATETIME类型（8个字节）存储时间 TIMESTAMP

explain显示了mysql如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。 使用方法，在select语句前加上explain就可以了： explain select surname,first_name form a,b where a.id=b.id 参数 table 。 表示这行数据是哪张表。 type 。显示连接使用了哪种类型。 null、 const/system、eq_ref、ref、range、index和ALL，从前到后，性能从最好变最差。 null。 表示不用访问表或者索引就能得到结果 const/system。 单表中最多只有一条匹配行。 eq_reg。 相对于ref来说就是使用的是唯一索引，对于每个索引键值，只有唯一的一条匹配记录（在联表查询中使用primary key或者unique key作为关联条件） ref。 使用非唯一性索引或者唯一索引的前缀扫描，返回匹配某个单独值的记录行 range。 索引范围扫描，常见于<、<=、>、>=、between等操作符 index。 索引全扫描，MYSQL遍历整个索引来查找匹配的行 ALL。 全表扫描，MYSQL扫描全表来找到匹配的行 possible_keys 。显示可能应用在这张表中的索引。如果为空，没有可能的索引 key 。 实际使用的索引 key_len 。

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