聚簇索引索引覆盖分析

聚簇索引

优势: 根据主键查询条目比较少时,不用回行(数据就在主键节点下)

劣势: 如果碰到不规则数据插入时,造成频繁的页分裂.

C) 聚簇索引的页分裂过程

实验: 聚簇索引使用随机值导致页频繁分裂影响速度

过程:建立innodb表, 利用php连接mysql,

分别规则插入10000条数据,不规则插入10000条数据

观察时间的差异,体会聚簇索引,页分裂的影响.

create table t5(

id int primary key,

c1 varchar(500),

c2 varchar(500),

c3 varchar(500),

c4 varchar(500),

c5 varchar(500),

c6 varchar(500)

) engine innodb charset utf8;

create table t6(

id int primary key,

c1 varchar(500),

c2 varchar(500),

c3 varchar(500),

c4 varchar(500),

c5 varchar(500),

c6 varchar(500)

) engine innodb charset utf8;

// testinnodb.php
$time_start = microtime_float();

$str = str_repeat(‘hello‘,100);

for($i=1;$i<=10000;$i++) {

$sql =
"insert into t5 values ($i,‘$str‘ , ‘$str‘ , ‘$str‘ , ‘$str‘ , ‘$str‘ ,
‘$str‘

)";

//echo
$sql;

mysql_query($sql , $conn);

}

$time_end = microtime_float();

echo ‘seq insert cost‘ , ($time_end - $time_start)
, "seconds\n";

function microtime_float()

{

list($usec, $sec) = explode(" ", microtime());

return
((float)$usec + (float)$sec);

}

// rndinnodb.php
$base = range(1,10000);

shuffle($base);

$time_start = microtime_float();

$str = str_repeat(‘hello‘,100);

foreach($base as $i) {

$sql =
"insert into t6 values ($i,‘$str‘ , ‘$str‘ , ‘$str‘ , ‘$str‘ , ‘$str‘ ,
‘$str‘

)";

//echo
$sql;

mysql_query($sql , $conn);

}

$time_end = microtime_float();

echo ‘rand insert cost‘ , ($time_end - $time_start)
, "seconds\n";

function microtime_float()

{

list($usec, $sec) = explode(" ", microtime());

return
((float)$usec + (float)$sec);

}


字段数


混乱程度(步长)


顺序1000条(秒数)


乱序1000条(秒数)


顺序写入page页数


乱序写入page数


1


1


54.365


53.438


62


91


10


1


53.413


62.940


235


1301


10


100


64.18


1329


10


1000


67.512


1325

通过上面的规律可以看出-----

1: innodb的buffer_page 很强大.

2: 聚簇索引的主键值,应尽量是连续增长的值,而不是要是随机值,

(不要用随机字符串或UUID)

否则会造成大量的页分裂与页移动.
高性能索引策略

0:对于innodb而言,因为节点下有数据文件,因此节点的分裂将会比较慢.

对于innodb的主键,尽量用整型,而且是递增的整型.

如果是无规律的数据,将会产生的页的分裂,影响速度.

索引覆盖:

索引覆盖是指 如果查询的列恰好是索引的一部分,那么查询只需要在索引文件上进行,不需要回行到磁盘再找数据.

这种查询速度非常快,称为”索引覆盖”

时间: 2024-08-12 18:46:11

聚簇索引索引覆盖分析的相关文章

DB索引、索引覆盖、索引优化

###########索引########### @see   http://mp.weixin.qq.com/s/4W4iVOZHdMglk0F_Ikao7A 聚集索引(clustered index):聚集索引决定数据在磁盘上的物理排序,一个表只能有一个聚集索引,一般用primary key来约束. 举例:t_user场景中,uid上的索引. 非聚集索引(non-clustered index):它并不决定数据在磁盘上的物理排序,索引上只包含被建立索引的数据,以及一个行定位符row-loca

MySQL索引优化分析和SQL优化

1 配置环境的说明 MySQL的版本信息: 系统版本信息: 2 索引的分析 2.1数据准备 2.1.1数据库建表SQL 表的说明: id是自增主键,name是唯一索引,age 是非唯一索引,desc无索引 CREATE TABLE `index_test` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增ID', `name` varchar(128) COLLATE utf8_bin NOT NULL DEFAULT ''

索引覆盖和DB2查寻性能

当索引包含查寻中所有的列,我们通常说索引包含查寻,任何时候发生这种情况时,DB2(DB2认证 DB2培训 )优化器通常选择只访问查寻所需的索引,称为的纯索引访问或索引覆盖.但“通常”并不意味着“总是”.例如,让我们考虑下面的图表结构: CREATETABLECONTACT( ZIPCODEINTNOTNULL, PHONE_NUMBERCHAR(10)NOTNULL, SOME_OTHER_STUFFVARCHAR(100)); CREATEINDEXCONTACT_ZIP_PHONEONCON

Mysql 索引优化分析

MySQL索引优化分析 为什么你写的sql查询慢?为什么你建的索引常失效?通过本章内容,你将学会MySQL性能下降的原因,索引的简介,索引创建的原则,explain命令的使用,以及explain输出字段的意义.助你了解索引,分析索引,使用索引,从而写出更高性能的sql语句.还在等啥子?撸起袖子就是干! 案例分析 我们先简单了解一下非关系型数据库和关系型数据库的区别. MongoDB是NoSQL中的一种.NoSQL的全称是Not only SQL,非关系型数据库.它的特点是性能高,扩张性强,模式灵

mySql索引优化分析

MySQL索引优化分析 为什么你写的sql查询慢?为什么你建的索引常失效?通过本章内容,你将学会MySQL性能下降的原因,索引的简介,索引创建的原则,explain命令的使用,以及explain输出字段的意义.助你了解索引,分析索引,使用索引,从而写出更高性能的sql语句.还在等啥子?撸起袖子就是干! 案例分析 我们先简单了解一下非关系型数据库和关系型数据库的区别.MongoDB是NoSQL中的一种.NoSQL的全称是Not only SQL,非关系型数据库.它的特点是性能高,扩张性强,模式灵活

【Mysql优化】索引覆盖

索引覆盖 是指 如果查询的列恰好是索引的一部分,那么查询只需要在索引文件上进行,不需要回行到磁盘再找数据.这种查询速度非常快,称为”索引覆盖”,比平时的查询少一次到磁盘读数据的操作.(索引正好覆盖到查询的数据) 例如下面: mysql> use exam9; Database changed mysql> desc options; +----------------+---------------+------+-----+---------+-------+ | Field | Type

SQL Server2005索引碎片分析和解决方法

SQL Server2005索引碎片分析和解决方法 本文作者(郑贤娴),请您在阅读本文时尊重作者版权. 摘要: SQL Server,为了反应数据的更新,需要维护表上的索引,因而这些索引会形成碎片.根据工作量的特征,这些碎片会影响对应的工作性能.此文帮助决定是否需要整理碎片以改善性能的信息.SQL Serve提供一些命令来实现索引的碎片整理.这里比较其中两个命令:DBCC DBREINDEX 和 DBCC INDEXDEFRAG. 关键词: SQL Server;索引碎片;数据库优化毫无疑问,给

oracle如何进行索引监控分析和优化

在生产环境.我们会发现: ① 索引表空间 I/O 非常高     ② "db file sequential read" 等待事件也比较高   这种迹象表明.整个数据库系统.索引的读写操作比较多.已经成为系统的主要瓶颈      一般的原因.大抵如下:   ① 大量SQL均采用索引   ② DML操作导致索引维护工作量暴增   ③ 频繁DML导致很多索引碎片.增加I/O开销   ④ 索引建立策略失误.走索引如同全表扫      如果.一张表字段30个.但索引竟有 50个!?   作为

[转]Oracle 索引质量分析

http://blog.csdn.net/leshami/article/details/23687137 索引质量的高低对数据库整体性能有着直接的影响.良好高质量的索引使得数据库性能得以数量级别的提升,而低效冗余的索引则使得数据库性能缓慢如牛,即便是使用高档的硬件配置.因此对于索引在设计之初需要经过反复的测试与考量.那对于已经置于生产环境中的数据库,我们也可以通过查询相关数据字典得到索引的质量的高低,通过这个分析来指导如何改善索引的性能.下面给出了演示以及索引创建的基本指导原则,最后给出了索引