聚簇索引

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

索引-80%优化处理 mysql 索引-存储。 1.优化索引。 2.最优索引。 普通sql - 好的索引-最优索引 索引优点：--索引本来就是有序 1.1：减少扫描量 1.2：避免排序+避免临时表产生 1.3：随机I/O变为顺序I/O 固定硬盘 ssd iops-每秒查询次数。 1.4：可以减少查询锁定行。 串行硬盘。 B+Tree索性--mysql索引 二叉搜索树。 平衡的m路搜索树 == 聚族索引 主键+补助建、 二次查询，但是io控制的好，不损失，减少维护成本。适合更新多的。 非聚族索性 都是 InnoDB ===================== 表空间-区-页-16-块-4 engine 14.6g 联合索引。 ========================================================= 避免where 字句中 对字段+函数,避免格式转化等函数，否则索引就无效。 最左原则。计算索引值。双B关联，字符类型不一致，关联会查询换较慢。 mysql。 避免关联拆sql处理。主从分离-读写分离。 service存控制了。 水平拆表。 避免使用子查询。 总数：1. count() 2.统计某列除null外的数量。 联合索引-一次查询 ============================================ 分页： limit 0

案例描述 在定时脚本运行过程中，发现当备份表格的sql语句与删除该表部分数据的sql语句同时运行时，mysql会检测出死锁，并打印出日志。 两个sql语句如下： （1）insert into backup_table select * from source_table （2）DELETE FROM source_table WHERE Id>5 AND titleWeight<32768 AND joinTime<'$daysago_1week' teamUser 表的表结构如下： PRIMARY KEY (`uid`,`Id`), KEY `k_id_titleWeight_score` (`Id`,`titleWeight`,`score`), ENGINE=InnoDB 两语句对source_table表的使用情况如下： 死锁日志打印出的时间点表明，语句（1）运行过程中，当语句（2）开始运行时，发生了死锁。 当mysql检测出死锁时，除了查看mysql的日志，还可以通过show InnoDB STATUS \G语句在mysql客户端中查看最近一次的死锁记录。由于打印出来的语句会很乱，所以，最好先使用pager less命令，通过文件内容浏览方式查看结果，会更清晰。（以nopager结束） 得到的死锁记录如下： 根据死锁记录的结果，可以看出确实是这两个语句发生了死锁

一、MySQL中索引的语法 1. 创建索引 1. 在创建表的时候添加索引 CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); 2. 在创建表以后添加索引 ALTER TABLE my_table ADD [UNIQUE] INDEX index_name(column_name); 或者 CREATE INDEX index_name ON my_table(column_name); 注意： 1、索引需要占用磁盘空间，因此在创建索引时要考虑到磁盘空间是否足够 2、创建索引时需要对表加锁，因此实际操作中需要在业务空闲期间进行 2. 根据索引查询 具体查询： SELECT * FROM table_name WHERE column_1=column_2;(为column_1建立了索引) 或者模糊查询 SELECT * FROM table_name WHERE column_1 LIKE '%三' SELECT * FROM table_name WHERE column_1 LIKE '三%' SELECT * FROM table_name WHERE column_1 LIKE '%三%' SELECT *

聚簇索引和非聚簇索引 分析了MySQL的索引结构的实现原理，然后我们来看看具体的存储引擎怎么实现索引结构的，MySQL中最常见的两种存储引擎分别是 MyISAM 和 InnoDB ，分别实现了 非聚簇索引 和 聚簇索引 。 聚簇索引 的解释是： 聚簇索引的顺序就是数据的物理存储顺序 非聚簇索引 的解释是： 索引顺序与数据物理排列顺序无关 （这样说起来并不好理解，让人摸不着头脑，清继续看下文，并在插图下方对上述两句话有解释） 首先要介绍几个概念，在索引的分类中，我们可以 按照索引的键是否为主键来分为“主索引”和“辅助索引” ，使用主键键值建立的索引称为“主索引”，其它的称为“辅助索引”。 因此主索引只能有一个，辅助索引可以有很多个。 MyISAM——非聚簇索引 MyISAM存储引擎采用的是非聚簇索引， 非聚簇索引的主索引和辅助索引几乎是一样的 ， 只是主索引不允许重复，不允许空值 ，他们的叶子结点的key都存储指向键值对应的数据的 物理地址。 非聚簇索引的数据表和索引表是 分开存储的 。 非聚簇索引中的数据是根据数据的插入顺序保存。因此非聚簇索引更适合单个数据的查询。 插入顺序不受键值影响 。 只有在MyISAM中才能使用FULLTEXT索引。(mysql5.6以后innoDB也支持全文索引) *最开始我一直不懂既然非聚簇索引的主索引和辅助索引指向相同的内容

前言：本文第一部分讨论数据库的索引及其优化，主要以sql server为例，第二部分我们从Mysql讨论它背后的数据结构和算法原理。 第一部分，数据库索引及其优化 一，什么是索引 　　数据库索引好比是一本书前面的目录，能加快数据库的查询速度。 　　例如这样一个查询：select * from table1 where id=44。如果没有索引，必须遍历整个表，直到ID等于44的这一行被找到为止；有了索引之后(必须是在ID这一列上建立的索引)，直接在索引里面找44（也就是在ID这一列找），就可以得知这一行的位置，也就是找到了这一行。可见，索引是用来定位的。 　　索引分为聚簇索引和非聚簇索引两种，聚簇索引 是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；显然在一个基本表上最多只能建立一个聚簇索引。建立聚簇索引后，更新该索引列上的数据时，往往导致表中记录的物理顺序的变更，代价较大，因此对于经常更新得列不宜建立聚簇索引，聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。建立一个聚簇索引如： create cluster index id on Student(id); 二，概述 　　建立索引的目的是加快对表中记录的查找或排序。 　　为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。 精简来说

MySQL非聚簇索引&&二级索引&&辅助索引 mysql中每个表都有一个聚簇索引（clustered index ），除此之外的表上的每个非聚簇索引都是二级索引，又叫辅助索引（secondary indexes）。 以InnoDB来说，每个InnoDB表具有一个特殊的索引称为聚集索引。如果您的表上定义有主键，该主键索引是聚集索引。如果你不定义为您的表的主键时，MySQL取第一个唯一索引（unique）而且只含非空列（NOT NULL）作为主键，InnoDB使用它作为聚集索引。如果没有这样的列，InnoDB就自己产生一个这样的ID值，它有六个字节，而且是隐藏的，使其作为聚簇索引。 聚簇索引： http://my.oschina.net/xinxingegeya/blog/474895 如下除主键外都是二级索引，或叫做辅助索引。 > show create table article ******************** 1. row ********************* Table: article Create Table: CREATE TABLE `article` ( `id` int(11) NOT NULL AUTO_INCREMENT, `title` varchar(255) NOT NULL, `shortName` varchar(255) NOT

表smth中有10000行数据，有两个3000长度的字段； select id from smth order by id ;很慢 select id from smth order by id,ver;比较快 原因？ create table smth( id int(11) not null default 0, ver int(11) default null, content varchar(3000) default null, intro varchar(3000) default null, primary key (id), key idver(id,ver) )engine =InnoDB default charset=utf8; create table mysmth( id int(11) not null default 0, ver int(11) default null, content varchar(3000) default null, intro varchar(3000) default null, primary key (id), key idver(id,ver) )engine =myisam default charset=utf8; delimiter $$ create procedure myproc () begin

参考： MySQL 加锁处理分析 。该文已经讲的很详尽了，也易懂，下面仅仅是个人做的总结。 一、 背景 1.1 隔离级别 1.2 加锁过程 　　 逐条处理，逐条加锁。 1.3 两阶段锁2PL 1.4 gap锁 　　gap锁是间隙锁，即相邻两条有效记录间隙的锁（锁的是间隙），它是 针对insert的，用来解决幻读的发生。 它会阻塞insert，但不会阻塞delete/update等（记录本来也不存在）。 　　RC与RR的重要区别就是幻读。所以RR才需要引入gap锁。 二、加锁组合分析 　　说加什么锁，首先要了解两个前提：1）隔离级别；2）用到的索引。不同的隔离级别，不同的索引都会影响加锁。 2.1 可提交读RC 主键/唯一键 二级索引 无索引 select 无 无 无 insert 行锁 行锁 行锁 select...for update/update/delete 行锁 有效行的行锁 全表锁聚簇索引 2.2 可重复读RR 主键/唯一键 二级索引 无索引 select 无 无 无 insert 行锁 行锁 行锁 select...for update/update/delete 行锁 有效行的行锁 +gap锁 全表锁聚簇索引 2.3 可序列化S 主键/唯一键 二级索引 无索引 select（快照读） S S S 其他（当前读） X X X 　　注意：无索引时，select...for

MySQL中一条SQL的加锁分析 id主键 + RC id唯一索引 + RC id非唯一索引 + RC id无索引 + RC id主键 + RR id唯一索引 + RR id非唯一索引 + RR id无索引 + RR Serializable 一条复杂的SQL 死锁原理与分析 SQL1： select * from t1 where id = 10;（不加锁。因为MySQL是使用多版本并发控制的，读不加锁。） SQL2: delete from t1 where id = 10;（需根据多种情况进行分析） 假设t1表上有索引，执行计划一定会选择使用索引进行过滤 (索引扫描)，根据以下组合，来进行分析。 组合一 ： id列是主键，RC隔离级别 组合二 ： id列是二级唯一索引，RC隔离级别 组合三 ： id列是二级非唯一索引，RC隔离级别 组合四 ： id列上没有索引，RC隔离级别 组合五 ： id列是主键，RR隔离级别 组合六 ： id列是二级唯一索引，RR隔离级别 组合七 ： id列是二级非唯一索引，RR隔离级别 组合八 ： id列上没有索引，RR隔离级别 组合九 ： Serializable隔离级别 注：在前面八种组合下，也就是RC，RR隔离级别下，SQL1：select操作均不加锁，采用的是快照读，因此在下面的讨论中就忽略了，主要讨论SQL2：delete操作的加锁。 1.