mysql 建复合索引_关于mysql建立索引 复合索引 索引类型

news/2024/7/7 19:48:42

这两天有个非常强烈的感觉就是自己在一些特别的情况下还是hold不住,脑子easy放空或者说一下子不知道怎么去分析问题了,比方,问“hash和btree索引的差别”,这非常难吗。仅仅要掌握了这两种数据结构稍加分析就能得出答案,结果是一下子不知道从何说起。进入正题吧。这两者有啥差别。

1. hash索引查找数据基本上能一次定位数据。当然有大量碰撞的话性能也会下降。

而btree索引就得在节点上挨着查找了,非常明显在数据精确查找方面hash索引的效率是要高于btree的。

2. 那么不精确查找呢,也非常明显,由于hash算法是基于等值计算的。所以对于“like”等范围查找hash索引无效,不支持;

3. 对于btree支持的联合索引的最优前缀。hash也是无法支持的。联合索引中的字段要么全用要么全不用。提起最优前缀竟然都泛起迷糊了,看来有时候放空得太厉害。

4. hash不支持索引排序。索引值和计算出来的hash值大小并不一定一致。

勤动脑,少放空。

索引是在数据库表或者视图上创建的对象,目的是为了加快对表或视图的查询的速度。

依照存储方式分为:聚集与非聚集索引

依照维护与管理索引角度分为:唯一索引、复合索引和系统自己主动创建的索引。

索引的结构是由:根节点--->非叶节点--->非叶节点--->叶节点

1、聚集索引:表中存储的数据依照索引的顺序存储,检索效率比普通索引高,但对数据新增/改动/删除的影响比較大。

逻辑顺序决定了表中对应行的物理顺序。

特点:

(1) 一个表能够最多能够创建249个索引

(2) 先建聚集索引才干创建非聚集索引

(3) 非聚集索引数据与索引不同序

(4) 数据与索引在不同位置

(5) 索引在叶节点上存储,在叶节点上有一个"指针"直接指向要查询的数据区域

(6) 数据不会依据索引键的顺序又一次排列数据

(7)假设在该字段上进行范围查询,或者该表非常少做增删改

创建聚集索引的语法:

create NONCLUSTERED INDEX idximpID ON EMP(empID)

2、非聚集索引:不影响表中的数据存储顺序,检索效率比聚集索引低,对数据新增/改动/删除的影响非常少

是通过二叉树的数据结构来描写叙述的,逻辑顺序,特点:

(1) 无索引。数据无序

(2) 有索引。数据与索引同序

(3) 数据会依据索引键的顺序又一次排列数据

(4) 一个表仅仅能有一个索引

(5) 叶节点的指针指向的数据也在同一位置存储

语法:

create CLUSTERED INDEX idxempID on emp(empID)

3、惟一索引:惟一索引能够确保索引列不包括反复的值.

能够用多个列,可是索引能够确保索引列中每一个值组合都是唯一的

姓   名

李   二

张   三

王   五

语法: create unique index idxempid on emp(姓,名)

4、复合索引:假设在两上以上的列上创建一个索引,则称为复合索引。

那么。不可能有两行的姓和名是反复的

语法:

create index indxfullname on addressbook(firstname,lastname)

注意:假设把复合的聚集索引字段分开查询。

带着这个问题。我们来看一下下面的查询速度(结果集都是25万条数据):(日期列fariqi首先排在复合聚集索引的起始列。usernameneibuyonghu排在后列):

(1)select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5''

查询速度:2513毫秒

(2)select gid,fariqi,neibuyonghu,title from Tgongwen where fariqi>''2004-5-5'' and neibuyonghu=''办公室''

查询速度:2516毫秒

(3)select gid,fariqi,neibuyonghu,title from Tgongwen where neibuyonghu=''办公室''

查询速度:60280毫秒

从以上试验中,我们能够看到假设仅用聚集索引的起始列作为查询条件和同一时候用到复合聚集索引的所有列的查询速度是差点儿一样的。甚至比用上所有的复合索引列还要略快(在查询结果集数目一样的情况下);而假设仅用复合聚集索引的非起始列作为查询条件的话,这个索引是不起不论什么作用的。当然,语句1、2的查询速度一样是由于查询的条目数一样。假设复合索引的所有列都用上,并且查询结果少的话,这样就会形成“索引覆盖”。因而性能能够达到最优。同一时候,请记住:不管您是否常常使用聚合索引的其它列,但其前导列一定要是使用最频繁的列。

5、系统自建的索引:在使用T_sql语句创建表的时候使用PRIMARY KEY或UNIQUE约束时。会在表上自己主动创建一个惟一索引

自己主动创建的索引是无法删除的

语法:

create table ABc

( empID int primary key,

firstname varchar(50)UNIQUE,

lastname   varchar(50)UNIQUE,

)

这种结果就出来了三个索引,但仅仅有一个聚集索引哦

6、创建索引的方法:

1、企业管理器中

(1)右击某个表,全部任务---管理索引,打开管理索引。单击“新建”就能够创建索引

(2)在设计表中进行设计表,管理索引/键

(3)在关系图中,加入表后右击关系图中的某个表,就有“索引/键”

(4)通过向导,数据库---创建索引向导

(5)通过T-SQL语句

2、能过“索引优化向导”来优化索引的向导。通过它能够决定选择哪些列做为索引列

二、何时使用聚集索引或非聚集索引

以下的表总结了何时使用聚集索引或非聚集索引(非常重要):

动作描写叙述

使用聚集索引

使用非聚集索引

列常常被分组排序

返回某范围内的数据

不应

一个或极少不同值

不应

不应

小数目的不同值

不应

大数目的不同值

不应

频繁更新的列

不应

外键列

主键列

频繁改动索引列

不应


http://lihuaxi.xjx100.cn/news/245799.html

相关文章

1-1 分配内存资源给容器和POD

这一小节讲解如何分配内存请求和对一个容器做内存限制。一个容器被保证拥有足够的内存可以处理请求,但是也不允许使用超过限制的内存。 开始之前 需要拥有一个k8s集群 需要安装好一个kubectl 工具,并且能够与集群通信。 如果没有准备好,你…

当你学了现在的忘了前面的

我怀疑我的智商应该不是很高,要不然我也不会学的如此狼狈。虽然我总是能很好的理解现在所学的知识点,但是我就是记不住,当下次再次需要上次的知识点来解决问题的时候,我总是忘的差不多了,要不就是没把握和对不对的问题…

属性 visibility

http://www.w3school.com.cn/cssref/pr_class_visibility.asp 可能的值 值描述visible默认值。元素是可见的。hidden元素是不可见的。collapse当在表格元素中使用时,此值可删除一行或一列,但是它不会影响表格的布局。被行或列占据的空间会留给其他内容使…

gff3转mysql_五月 | 2013 | 陈连福的生信博客

1. GBrowse的安装GBrowse安装说明文档:http://gmod.org/wiki/GBrowse_2.0_Install_HOWTOGBrowse的安装很少有能顺利安装成功的。需要不断的摸索,看文档,并搜索相关错误,google看别人是怎么解决的。有管一些我安装过程遇到的困难如…

在typescript中导入第三方类库import报错

问题 最近开始折腾typescript,在使用第三方类库,比如最常见的lodash,采用常规方法导入 import * as _ from lodashvscode中报错提示lodash不是module。 原因 因为第三方类库并没有ts的声明文件,查阅网上资料,有typings…

SSAS系列——【07】多维数据(查询Cube)

原文:SSAS系列——【07】多维数据(查询Cube)1、什么是MDX? MDX叫做“多维表达式”,是一种查询语言,是一种和SQL类似的查询语言,它基于 XML for Analysis (XMLA) 规范,并带有特定于 SQL Server A…

mysql-5.5.25_Linux下安装Mysql-5.5.25

Mysql安装前准备首先将依赖的开发工具全部装上yum -y install gcc gcc-c autoconf libjpeg libjpeg-devel libpng libpng-devel freetype freetype-devel libxml2 libxml2-devel zlib zlib-devel glibc glibc-devel glib2 glib2-devel bzip2 bzip2-devel ncurses ncurses-devel…

linux 由一个文件夹复制到另外一个文件夹

cp -Rf /home/user1/* /root/temp/将 /home/user1目录下的所有东西拷到/root/temp/下而不拷贝user1目录本身。即格式为:cp -Rf 原路径/ 目的路径/转载于:https://blog.51cto.com/2841314881/1711551