MySQL索引与性能(2) 聚簇索引

聚簇索引是一种数据存储方式,它实际上是在同一个结构中保存了B+树索引和数据行,InnoDB表是按照聚簇索引组织 的(类似于Oracle的索引组织表)。

InnoDB通过主键聚簇数据,如果没有定义主键,会选择一个唯一的非空索引代替,如果没有这样的索引,会隐式定义 个主键作为聚簇索引。

下图形象说明了聚簇索引表(InnoDB)和普通的堆组织表(MyISAM)的区别:

对于普通的堆组织表来说(右图),表数据和索引是分成存储的,主键索引和二级索引存储上没有任何区别。

而对于聚簇索引表来说(左图),表数据是和主键一起存储的,主键索引的叶结点存储行数据,二级索引的叶结点存 储行的主键值。

聚簇索引表最大限度地提高了I/O密集型应用的性能,但它也有以下几个限制:

1)插入速度严重依赖于插入顺序,按照主键的顺序插入是最快的方式,否则将会出现页分裂,严重影响性能。因此 ,对于InnoDB表,我们一般都会定义一个自增的ID列为主键。

2)更新主键的代价很高,因为将会导致被更新的行移动。因此,对于InnoDB表,我们一般定义主键为不可更新。

3)二级索引访问需要两次索引查找,第一次找到主键值,第二次根据主键值找到行数据。

二级索引的叶节点存储的是主键值,而不是行指针,这是为了减少当出现行移动或数据页分裂时二级索引的维护工作 ,但会让二级索引占用更多的空间。

查看本栏目更多精彩内容:http://www.bianceng.cnhttp://www.bianceng.cn/database/MySQL/

时间: 2024-08-02 15:32:00

MySQL索引与性能(2) 聚簇索引的相关文章

MySQL索引与性能(3) 覆盖索引

覆盖索引是指索引的叶子节点已包含所有要查询的列,因此不需要访问表数据,能极大地提高性能.覆盖索引对 InnoDB的聚簇索引表特别有用,因为可以避免InnoDB二级索引的二次查询.MySQL里只有B树索引能做覆盖索引,因为必 须要存储索引列的值,而哈希索引.空间索引.全文索引不可以. 当发起一个覆盖索引的查询时,在explain的Extra列可以看到Using Index,下面看一个例子,在表users有一个多列 索引(login_id,status),执行计划如下 root@test 01:30

MySQL索引与性能(4) 排序

我们知道B树索引是有序的,那么可不可以通过只扫描索引就能完成order by操作呢?答案是肯定的,但条件也比较 苛刻:只有当索引的列顺序和order by字句的列顺序完全一致,且order by字句中所有列的排序方式要么全部都是ASC, 要么全部都是DESC,MySQL才能使用索引来对结果进行排序:如果查询需要关联多个表,则条件更苛刻,只有当order by 字句中的列全部为驱动表(执行计划中)时,才能使用索引做排序. 下面我们来看一些例子:假设users表上有索引(login_id,statu

MySQL索引与性能(1) 索引类型

本文讨论MySQL支持的索引类型及其优缺点.要注意的是:在MySQL中,索引是在存储引擎层而不是服务器层实现,所 以不同存储引擎的索引的工作方式并不一样,也不是所有的存储引擎都支持所有类型的索引. B+树索引 B+树是一种经典的数据结构,由平衡树和二叉查找树结合产生,它是为磁盘或其它直接存取辅助设备而设计的一种平 衡查找树,在B+树中,所有的记录节点都是按键值大小顺序存放在同一层的叶节点中,叶节点间用指针相连,构成双向 循环链表,非叶节点(根节点.枝节点)只存放键值,不存放实际数据.下面看一个2

MySQL索引实战经验总结

MySQL索引对数据检索的性能至关重要,盲目的增加索引不仅不能带来性能的提升,反而会消耗更多的额外资源,本篇总结了一些MySQL索引实战经验. 索引是用于快速查找记录的一种数据结构.索引就像是数据库中数据的目录,数据库在查询时,首先在索引中找到匹配的值,然后根据这个匹配值找到对应的数据行. 概念解释 聚簇索引 聚簇索引的顺序就是数据的物理存储顺序,索引中数据域存储的就是实际的数据,一个表最多只能有一个聚簇索引,适用于查询多行数据,不适用于频繁修改的列,一般在主键上创建. 非聚簇索引 索引顺序与数

MySQL索引及查询优化总结 专题

  小结:db名与应用名相同,表名:业务名_此表的作用 ,表名表示内容,不体现数量,如果表示boolean概念,表名需要使用is_业务含义来表示,但POJO中不应该出现isXXX,因为不方便序列化,中间的对应关系,使用ResultMap来映射字段名中有多个单词,使用下划线连接,字段名不能以数字打着,数字和单词之间,只需要一个下划线,譬如xx_3xx,不建议写成xx_3_xx最左前缀原则    如果是联合索引,Btree索引在使用时受索引建立的字段顺序的影响where条件中有or,建议拆成unio

理解MySQL——索引与优化

写在前面:索引对查询的速度有着至关重要的影响,理解索引也是进行数据库性能调优的起点.考虑如下情况,假设数据库中一个表有10^6条记录,DBMS的页面大小为4K,并存储100条记录.如果没有索引,查询将对整个表进行扫描,最坏的情况下,如果所有数据页都不在内存,需要读取10^4个页面,如果这10^4个页面在磁盘上随机分布,需要进行10^4次I/O,假设磁盘每次I/O时间为10ms(忽略数据传输时间),则总共需要100s(但实际上要好很多很多).如果对之建立B-Tree索引,则只需要进行log100(

详解mysql索引总结----mysql索引类型以及创建_Mysql

关于MySQL索引的好处,如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话,那么没有设计和使用索引的MySQL就是一个人力三轮车.对于没有索引的表,单表查询可能几十万数据就是瓶颈,而通常大型网站单日就可能会产生几十万甚至几百万的数据,没有索引查询会变的非常缓慢.还是以WordPress来说,其多个数据表都会对经常被查询的字段添加索引,比如wp_comments表中针对5个字段设计了BTREE索引.  一个简单的对比测试 以我去年测试的数据作为一个简单示例,20多条数据源随机生成200万

mysql索引优化与注意事项

mysql索引注意事项 以前对索引不是很重视,直到处理大数据的时候才发现,只是优化程序不管数据库是极其不对的,有无索引性能差异不是程序控制可以想象的; 简要列出几个通用的创建索引的说明,下列来源于网络(值得注意的几点) 1,创建索引 对于查询占主要的应用来说,索引显得尤为重要.很多时候性能问题很简单的就是因为我们忘了添加索引而造成的,或者说没有添加更为有效的索引导致.如果不加 索引的话,那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描,如果一张表的数据量很大而符合条件的结果又很少,那么不加

MySQL索引类型以及创建

文章归属:http://feiyan.info/16.html 关于MySQL索引的好处,如果正确合理设计并且使用索引的MySQL是一辆兰博基尼的话,那么没有设计和使用索引的MySQL就是一个人力三轮车.对于没有索引的表,单表查询可能几十万数据就是瓶颈,而通常大型网站单日就可能会产生几十万甚至几百万的数据,没有索引查询会变的非常缓慢.还是以WordPress来说,其多个数据表都会对经常被查询的字段添加索引,比如wp_comments表中针对5个字段设计了BTREE索引. 一个简单的对比测试 以我