什么样的字段不适合创建索引呢?
同样,对于有些列不应该创建索引
1. 对于那些查询中很少使用或者参考的列不应该创建索引,就是我查的过程当中,where语句当中没有,这样的东西你不建他,
建了反而不是什么好事既然在这些列上很少使用,既然在这些列上很少使用,因此有索引和无索引并不能提高查询速度
相反,由于增加了索引,反而降低了系统的维护速度和增大了空间需求,索引见多了还浪费空间,有人说索引不就是存一个
值吗,能有多大,索引在千万条以上的,你要是索引建多了,轻轻松松索引就可以达到一个G以上,1G可不是1M啊,有人说1G没事
我现在硬盘都1T了,但是1G不只是存索引啊,还有数据呢,所以你这么划分下来随着数据的增长,1T也不够折腾啊,而且这个空间
越大,牺牲的效率就越高,把多块性能一般的磁盘,通过磁盘阵列的技术,整合成一块,但是数据仍然是分布式的用,根Redis的
分片存储是一样的,这么做的好处相比你用一块硬盘,虽然你硬盘数量上来了
2. 对于那些只有很少数据值的列,也不需要创建索引,这是因为这些列的取值很少,例如人事表的性别列,在查询的结果中,
结果集的数据行占了表中数据行的很大比例,即需要在表中搜索的数据行的比例很大,增加索引,并不能明显的加快检索速度
所以这样的也要考虑清楚
3. 对于那些定义为text,image和bit数据类型的列不应该增加索引,你想想是不是这样的,text不是大文本吗,image也是一个大
字节,binary不都是大字节对象吗,这是因为这些列的数据要么相当大,要么取值很少,这些都是不适合建索引的,其实这块还可以
额外的再扩展一些,比如我是做电商的,有一个商品描述,还记得吗,tb_item_desc,item_desc text,这不是text吗,这个东西最复杂的
地方,淘宝当时在存描述的时候,对于这个字段是老的不亲,新的不爱的字段,哪个表都不愿意接受这个字段,为什么,因为这个表存的
数据量大,在检索的过程当中,可能因为他的数据影响整个效率,确实是这样的,后来怎么着,其实商品描述是应该在商品信息表里的,
因为你本来就属于我的一部分,后来专门建立一个表,这表什么都不放,只存商品信息,那其实你发现,你在商品存信息的时候,
这个信息和商品信息不是一次能够查出来的,先查商品的基本信息,然后再去查询商品描述,那让用户有更好的体验效果,
还有以前说过,我做开发的时候,当是我们把海报存到数据库里,后来发现效率极低,原因就是跟存这个海报有关系,所以速度大而且
次数频繁,性能就低,后来图片存在系统的磁盘当中,至少保证数据库的性能不会受太大的影响,所以我们这个例子和他正好是两种
解决方案,它是必须要存到数据库的,因为他是文本,他不是图片,所以单独拆分出一张表,而我们是图片,是直接可以存在文件当中的,
那你未来在做项目的时候,如果真的是有这样的需求,大文本的字段你可以单独放在一起,因为他是比较容易拉低性能的,
像这样的都不建议建立索引,但不是说他不能建,有一种叫做全文检索的索引,倒也可以用到上面,一会咱们会说,不是吧所有字段
都作为索引的值,比如我把一大串作为索引遍历
4. 索引是为了提高查询性能,当你这个表的DML语句远大于查询,这个表想都不用想,任何字段都不要建索引,那这种策略是什么呢,
就是表通过建索引来提高或者优化你的查询性能,而且如果有这样的需求,通过创建索引来提高查询,性能会成指数递增,真的就是
这么神奇,通过建立索引来提升性能,这是好多程序员或者DBA最喜欢用的一个法宝
我们看看MYSQL对于索引的支持,其实MYSQL对于索引的支持,这里提到了一个B-TREE索引,Full-Text索引
什么叫B-TREE索引呢?
就是所有的索引节点都按照 Balance Tree,所有的索引数据节点都在叶子节点,这块简单介绍一下,B-TREE什么特点,我简单画个图,
这是不是一个典型的树型数据结构,树是不是支持排序的,这是不是一棵树,[1,2,3,4,5],你可以把它看成索引,咱们再强调一下,索引
会存在什么位置来着,是不是磁盘,文件吗,他有一个叫磁盘列的东西,一会我就讲磁盘列,比如说我现在想找索引为3的节点,我得对
这棵树进行几次查找,才能拿到呢,是不是先从5开始找,发现5下面是4和6,是不是从4节点往下找,第二次是从4节点往下找,4节点下
只有2没有3,是不是要再往下找一次再到2,当我找到2的时候已经找了几次了,3次吧,然后2再往下找会找到3,是不是一共找了4次,
也就是对这棵树遍历,最坏的情况下需要找4次,是什么引起的必须要找4次呢,是因为树的阶,树的阶是干什么呢,是树的高度,
那最坏的可能是在树的最底下,高度决定你要找多少次,找4,一次两次,但是这是对内存当中的树,但是现在索引是存在磁盘里,
大家知不知道计算机中有一个叫虚拟内存的东西,虚拟内存是为了更好的腾出空间的,比如一段时间之内,内存中的数据没用,
但是他不敢把它清空,就通过IO把文件读取,那么我们确认一件事,所以我们有磁盘列,那我是不是要IO四次才能找到,所以说怎么
才能解决这个问题呢,B树就能很好的解决这个问题,B树是从哪入手的呢,就是我降低你树的阶,就是把这棵树尽量给你压扁,
降低它的阶了,他IO次数就会少了,那降阶怎么降呢,其实你要知道那个公式原理,也就没那么复杂,其实最终就是什么呢,它的数据
可以这么存,比如对于1,2,3,4这几个节点来讲,他可以让1存在这,然后2,3存到这儿,然后4存到这,再加一个节点,你要知道B-TREE
的最终目的是把一个树形结构给压扁,降低它的阶,降低阶带来的好处就是降低IO次数,所以这里是一个B-TREE的特点,你要感兴趣可以
自己取看一看,按照那个公式存储就可以套进来,也不是什么难的事,所以说MYSQL里面存索引,大部分都是依赖这个B-TREE,
我们一会也可以自己建索引,他的索引也是B-TREE类型
还有一个叫Full-Text索引,Full-text索引就是我们说的全文检索,他的结构也是B-TREE形式的,主要是为了解决我们like查询效率低
的问题,主要是针对like,以后会说一下,当然MYSQL里面除了有这些,他还有比如R-TREE,但是那都不是我们要讲的内容,最重要的是
要讲B-TREE和Full-TEXT
说了这么多了,我们也知道索引的优点了,也知道索引的缺点了,知道在那种情况下给哪个字段建索引了,接下来我们的去创建索引
我们怎么给一个字段建索引呢,那相比ORACLE来讲,MYSQL创建索引那个工具,并没有像我们的PL/SQL,左侧是罗列出数据库常见对象,
里面就有一个index,你直接在可视化的视图下,就可以给你的表列创建索引,但是MYSQL的navicat没有提供这样的工具,那么也就意味着
我们还得通过创建索引的命令去创建,好在创建索引的命令并不是很复杂,下面我就做了非常的详细了