15.尚硅谷_MySQL高级_索引优势劣势.avi原创

那么呢，先给大家呢，做一个简单的两三分钟的复习，首先什么是索引好，那么这个时候我们将会获得索引是不是排序加查找两大功能呢？那么呢，第二次来说一个解决while后面那些各种字段是否查的快，条件上拼装组合，第二个解决orderby，排序的时候如何查找的快，简单而言，同学们抬头假设你要做一套电信的系统，是不是一定会有按照是吧？手机号码查询啊，各位亲，手机号码第一位你要是telephone number这个字段自我的排序，你跟我讲这个时候排好序的数字是不是11位手机号码都是零到九啊，第一位是一，我就可以按照主人。

你建的索引给我排好的顺序，我迅速的定位到，而是不是就避免了永远都是从120123456789的去搜，搜到采用，而我现在是不是可以迅速定位到啊，那么所以说我们呢，大家呢可以看一下结合，所以呢以后我们来看看，所以呢它有些什么样的优势和什么样的劣势，就如同一个硬币有两面，咱们是不是得好坏都得看看啊。首先我们呢要明白第一个类似大学图书馆建书目的索引，提高数据的什么效率，降低了什么成本，我们也知道哈，昨天我们说过抬头左边咱们是不是一张表，假设有100万，第一找OK，兄弟，你进去找书吧，从第一条刷到第100万，我们说过了，你牛，你运气好。

第一本就是算找到了咱们阿弥陀佛，但你倒霉的时候可能是不是要翻62万甚至是100万本书，全不要扫描啊，那么这个时候呢，如果你磁盘IO上频繁100多万次的IO，那么这个时候各位亲，很恐怖的一件事情吧，但是假设我们有那个索引，就跟我们昨天的B数量类似的平衡数量结构，好给你一个参考中值，这本书的编码是153，中间值是90，比它大的往右，比它小的靠左，那么90以前的是不是就过滤了，逐步往下走的话，这个数的高度是不是就变成你查找的字数的维度啊？假设这个数最高它是三层，那么最多是不是也就炒三层啊？OK，那么待会呢，还会说这种数的时候，到时候再再试试哈，再来第二个，通过索引面对数据进行了什么呀，也就是说比如说像我们。

说的要找book name telephone number，手机号这种字段，现在这一列，但是这一列它book name是不是一个column这么一个一列一个字段，在这一列上面加了索引，也就是说你查的快是因为我给你排好序了，比如说那些英文字母MYQL，你是不是最好一口气先定位到二，再定义到Y，再定义到SQL，这样你是不是不用每一个字母的查找，每一个字段的查找都要全表扫描啊，那么所以说第一种是降低了，是提高了数据检索效率，降低IO成本，第二种是对数据列进行了排序，降低数据的排序成本，降低了CPU的消耗。说白了，从硬件这个层次而言，是不是一个是IO，一个是运算CPU啊，好，这是它的优势。那么简单而言，就是我们所说的，一提高数据的检索效率。二降低数。

据的排序成本，也即我们所说的排好序的快速查找的数据结构，干两事，排序和查找OK，好，那么劣势呢，抬头，那杨哥，既然你这么说这个索引这么牛，反正U排好是有查好的话，我一张表开心一下，可能一张表大表80个字段，你们上生产环境这种也常见，那请问我干脆一不做二不休，我对这张表呢，每个字段都见索引，干他80个索引。第二个问题，好，我们先说第一个问题，同学们一张表从纯粹的技术理论上来说，我就这么干，我每个字段针对于某一个字段就建一个单值索引可否？但大家觉得这么干合适吗？因为我们也知道前面我们昨天说过，左边是表。

含列着一张table，右边是个索引数吧，所以要不要占磁盘空间的空间，那么言下之意，你各种频繁的变更，你这有80个书，就好比说你前面的图书馆，那个图书馆管理员是不是只应该用一套索引图书的检索系统，会不会有100万套，每本书做一套好，那么这个时候这是第一个问题，第二个大家思考。我们在日常工作中是建单值索引多呢，还是应该建符合索引多，符合索引，也就是说你思考一下，你去淘宝京东或者你自己做的电商系统，最上面是不是有一个form表单，筛选调整各种条件，你觉得你在查一个东西的时候，你是只会选一个条件查，还是会选多个，一般而言是不是会选多个呀？那么这个时候呢，我们呢，来看看索引呢，它的劣势呢，是有这些问题，第一个实际上而言，索引也是以什么该表保存了主键与索引字段，并指向实体表的记录，有没有点像我们Java里面的索引，其实是不是有点像等号左边的引用指向一个实际的数据和一个对象啊索引，索引列也是要占空间的，听懂。第二。

问题，虽然索引大大提高了什么速度啊，但是就会降低什么什么东西啊，主山是不会哈。听懂了吧，沙比较小，你你当然我们也说过是不是尽量，因为到后面我们会讲一个东西叫间隙，所听懂了就是，就像是假设我这四个突然有一个断了，那么这块是是有个间隙了，好，那回头我们会说哈，如果对表进行插入修改，Delete，因为更新表的时候，说白了这些东西是不是都是一种写操作，MYSQL不仅要保存一下你真实的数据，还要保存一下索引文件，每次更新添加了索引列的字段，以及重新的指向等等，都会调整因为更新所带来的建制变化后的索引信息，也就是说你不但改数据，是不是还会改了这个数据的索引啊，好，就像我们说，比如说OK，天龙八部这本书从三号柜子挪到了七号柜子，好，这本书这个纯粹的数据是不是发生了物理位置上的变更，你这改了，请问你图书管理员的那个系统的索引目录的。

指向要不要改好，要改就一下，否则是不是就无效，就错乱了，好那么再来，所以只是提高效率的一个因素，如果你的MYSQL有大数据量的表，就需要花时间研究建立最优秀的索引，注意这句话，花时间研究建立最优秀的索引，说明这个索引是什么，就像我们说的京东的那些东西，或者你要做模套系统，你第一版你只是猜测客户可能会按照这样的字段去查，我先去见到这个字段上面，但是后来根据你的点击率分析和客户所筛选的条件发现，诶，怎么针对这个事情，客户习惯于这么查，那么各位亲，那个索引是不是要不停的优化和调整啊，待会儿呢，我们呢会看一个案例。

故意的呢，埋个雷给大家铲一下，你会发现哦，原来这个索引都是根据不停的分析，删了键见了删，删了键，键了删逐步是吗？优化出来的，听懂好，那么呢，我们这儿呢，他的就是说索引建立呢，不是一朝一夕的哈，有时候呢，变更业务环境等等都需要呢，人为的呢去处理好。