——转自网络 https://www.dandelioncloud.cn/article/details/1525721910449291266

很多人不知道SQL语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。比如：

select * from table1 where name=’zhangsan’ and tID > 10000

和执行:

select * from table1 where tID > 10000 and name=’zhangsan’

一 些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的 10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name=’zhangsan’的，而后再根据限制条件条件tID> 10000来提出查询结果。

事实上，这样的担心是不必要的。SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。

虽然查询优化器可以根据where子句自动的进行查询优化，但大家仍然有必要了解一下“查询优化器”的工作原理，如非这样，有时查询优化器就会不按照您的本意进行快速查询。

在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。

SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值得范围内的匹配或者两个以上条件的AND连接。形式如下：

列名 操作符 <常数 或 变量>

或

<常数 或 变量> 操作符列名

列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。如：

Name=’张三’

价格>5000

5000<价格

Name=’张三’ and   价格>5000

如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。所以一个索引对于不满足SARG形式的表达式来说是无用的。

介绍完SARG后，我们来总结一下使用SARG以及在实践中遇到的和某些资料上结论不同的经验：

1、Like语句是否属于SARG取决于所使用的通配符的类型

如：name like ‘张%’ ，这就属于SARG

而：name like ‘%张’ ,就不属于SARG。

原因是通配符%在字符串的开通使得索引无法使用。

2、or 会引起全表扫描

Name=’张三’ and 价格>5000 符号SARG，而：Name=’张三’ or 价格>5000 则不符合SARG。使用or会引起全表扫描。

3、非操作符、函数引起的不满足SARG形式的语句

不满足SARG形式的语句最典型的情况就是包括非操作符的语句，如：NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等，另外还有函数。下面就是几个不满足SARG形式的例子：

ABS(价格)<5000

Name like ‘%三’

有些表达式，如：

WHERE 价格*2>5000

SQL SERVER也会认为是SARG，SQL SERVER会将此式转化为：

WHERE 价格>2500/2

但我们不推荐这样使用，因为有时SQL SERVER不能保证这种转化与原始表达式是完全等价的。

4、IN 的作用相当与OR

语句：

Select * from table1 where tid in (2,3)

和

Select * from table1 where tid=2 or tid=3

是一样的，都会引起全表扫描，如果tid上有索引，其索引也会失效。

5、尽量少用NOT

6、exists 和 in 的执行效率是一样的

很 多资料上都显示说，exists要比in的执行效率要高，同时应尽可能的用not exists来代替not in。但事实上，我试验了一下，发现二者无论是前面带不带not，二者之间的执行效率都是一样的。因为涉及子查询，我们试验这次用SQL SERVER自带的pubs数据库。运行前我们可以把SQL SERVER的statistics I/O状态打开。

（1）select title,price from titles where title_id in (select title_id from sales where qty>30)

该句的执行结果为：

表 ‘sales’。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 ‘titles’。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

（2）select title,price from titles where exists (select * from sales where sales.title_id=titles.title_id and qty>30)

第二句的执行结果为：

表 ‘sales’。扫描计数 18，逻辑读 56 次，物理读 0 次，预读 0 次。

表 ‘titles’。扫描计数 1，逻辑读 2 次，物理读 0 次，预读 0 次。

我们从此可以看到用exists和用in的执行效率是一样的。

7、用函数charindex()和前面加通配符%的LIKE执行效率一样

前面，我们谈到，如果在LIKE前面加上通配符%，那么将会引起全表扫描，所以其执行效率是低下的。但有的资料介绍说，用函数charindex()来代替LIKE速度会有大的提升，经我试验，发现这种说明也是错误的：

select gid,title,fariqi,reader from tgongwen where charindex(‘刑侦支队’,reader)>0 and fariqi>’2004-5-5’

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

select gid,title,fariqi,reader from tgongwen where reader like ‘%’ + ‘刑侦支队’ + ‘%’ and fariqi>’2004-5-5’

用时：7秒，另外：扫描计数 4，逻辑读 7155 次，物理读 0 次，预读 0 次。

8、union并不绝对比or的执行效率高

我们前面已经谈到了在where子句中使用or会引起全表扫描，一般的，我所见过的资料都是推荐这里用union来代替or。事实证明，这种说法对于大部分都是适用的。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’ or gid>9990000

用时：68秒。扫描计数 1，逻辑读 404008 次，物理读 283 次，预读 392163 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid>9990000

用时：9秒。扫描计数 8，逻辑读 67489 次，物理读 216 次，预读 7499 次。

看来，用union在通常情况下比用or的效率要高的多。

但经过试验，笔者发现如果or两边的查询列是一样的话，那么用union则反倒和用or的执行速度差很多，虽然这里union扫描的是索引，而or扫描的是全表。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’ or fariqi=’2004-2-5’

用时：6423毫秒。扫描计数 2，逻辑读 14726 次，物理读 1 次，预读 7176 次。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-9-16’

union

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’2004-2-5’

用时：11640毫秒。扫描计数 8，逻辑读 14806 次，物理读 108 次，预读 1144 次。

9、字段提取要按照“需多少、提多少”的原则，避免“select *”

我们来做一个试验：

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用时：4673毫秒

select top 10000 gid,fariqi,title from tgongwen order by gid desc

用时：1376毫秒

select top 10000 gid,fariqi from tgongwen order by gid desc

用时：80毫秒

由此看来，我们每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。

10、count(*)不比count(字段)慢

某些资料上说：用*会统计所有列，显然要比一个世界的列名效率低。这种说法其实是没有根据的。我们来看：

select count(*) from Tgongwen

用时：1500毫秒

select count(gid) from Tgongwen

用时：1483毫秒

select count(fariqi) from Tgongwen

用时：3140毫秒

select count(title) from Tgongwen

用时：52050毫秒

从 以上可以看出，如果用count(*)和用count(主键)的速度是相当的，而count(*)却比其他任何除主键以外的字段汇总速度要快，而且字段越 长，汇总的速度就越慢。我想，如果用count(*)， SQL SERVER可能会自动查找最小字段来汇总的。当然，如果您直接写count(主键)将会来的更直接些。

11、order by按聚集索引列排序效率最高

我们来看：（gid是主键，fariqi是聚合索引列）

select top 10000 gid,fariqi,reader,title from tgongwen

用时：196 毫秒。 扫描计数 1，逻辑读 289 次，物理读 1 次，预读 1527 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid asc

用时：4720毫秒。 扫描计数 1，逻辑读 41956 次，物理读 0 次，预读 1287 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by gid desc

用时：4736毫秒。 扫描计数 1，逻辑读 55350 次，物理读 10 次，预读 775 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi asc

用时：173毫秒。 扫描计数 1，逻辑读 290 次，物理读 0 次，预读 0 次。

select top 10000 gid,fariqi,reader,title from tgongwen order by fariqi desc

用时：156毫秒。 扫描计数 1，逻辑读 289 次，物理读 0 次，预读 0 次。

从以上我们可以看出，不排序的速度以及逻辑读次数都是和“order by 聚集索引列” 的速度是相当的，但这些都比“order by 非聚集索引列”的查询速度是快得多的。

同时，按照某个字段进行排序的时候，无论是正序还是倒序，速度是基本相当的。

12、高效的TOP

事实上，在查询和提取超大容量的数据集时，影响数据库响应时间的最大因素不是数据查找，而是物理的I/0操作。如：

select top 10 * from (

    select top 10000 gid,fariqi,title from tgongwen

       where neibuyonghu=’办公室’

           order by gid desc

) as a

order by gid asc

这 条语句，从理论上讲，整条语句的执行时间应该比子句的执行时间长，但事实相反。因为，子句执行后返回的是10000条记录，而整条语句仅返回10条语句， 所以影响数据库响应时间最大的因素是物理I/O操作。而限制物理I/O操作此处的最有效方法之一就是使用TOP关键词了。TOP关键词是SQL SERVER中经过系统优化过的一个用来提取前几条或前几个百分比数据的词。经笔者在实践中的应用，发现TOP确实很好用，效率也很高。

                                       聚集索引和非聚集索引

转载自：CSDN https://blog.csdn.net/riemann_/article/details/90324846

一、深入浅出理解索引结构

      实际上，可以把索引理解为一种特殊的目录。微软的SQL SERVER提供了两种索引：聚集索引（clustered 

index，也称聚类索引、簇集索引）和非聚集索引（nonclustered index，也称非聚类索引、非簇集索引）

。下面，我们举例来说明一下聚集索引和非聚集索引的区别：

      其实，我们的汉语字典的正文本身就是一个聚集索引。比如，我们要查“安”字，因为“安”的拼音是

“an”，而按照拼音排序汉字的字典是以英文字母“a”开头并以“z”结尾的，那么“安”字就自然地排

在字典的前部。如果您翻完了所有以“a”开头的部分仍然找不到这个字，那么就说明您的字典中没有这个

字。也就是说，字典的正文部分本身就是一个目录，您不需要再去查其他目录来找到您需要找的内容。我

们把这种正文内容本身就是一种按照一定规则排列的目录称为“聚集索引”。

       如果遇到不认识的字，不知道它的发音，这时候，需要去根据“偏旁部首”查到您要找的字，然后根据这

个字后的页码直接翻到某页来找到您要找的字。但您结合“部首目录”和“检字表”而查到的字的排序并

不是真正的正文的排序方法，比如您查“张”字，我们可以看到在查部首之后的检字表中“张”的页码是

672页，检字表中“张”的上面是“驰”字，但页码却是63页，“张”的下面是“弩”字，页面是390页。

很显然，这些字并不是真正的分别位于“张”字的上下方，现在您看到的连续的“驰、张、弩”三字实际

上就是他们在非聚集索引中的排序，是字典正文中的字在非聚集索引中的映射。我们可以通过这种方式来

找到您所需要的字，但它需要两个过程，先找到目录中的结果，然后再翻到您所需要的页码。我们把这种

目录纯粹是目录，正文纯粹是正文的排序方式称为“非聚集索引”。

       通过以上例子，我们可以理解到什么是“聚集索引”和“非聚集索引”。进一步引申一下，我们可以很容

易的理解：每个表只能有一个聚集索引，因为目录只能按照一种方法进行排序。

二、区别及优缺点

区别：

聚集索引一个表只能有一个，而非聚集索引一个表可以存在多个

聚集索引存储记录是物理上连续存在，而非聚集索引是逻辑上的连续，物理存储并不连续

聚集索引:物理存储按照索引排序；聚集索引是一种索引组织形式，索引的键值逻辑顺序决定了表数据行的

物理存储顺序。

非聚集索引:物理存储不按照索引排序；非聚集索引则就是普通索引了，仅仅只是对数据列创建相应的索引

，不影响整个表的物理存储顺序。

索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非

聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。

优势与缺点：

聚集索引插入数据时速度要慢（时间花费在“物理存储的排序”上，也就是首先要找到位置然后插入），

查询数据比非聚集数据的速度快。

三、需要搞清楚的几个问题

第一：聚集索引的约束是唯一性，是否要求字段也是唯一的呢？

分析：如果认为是的朋友，可能是受系统默认设置的影响，一般我们指定一个表的主键，如果这个表之前

没有聚集索引，同时建立主键时候没有强制指定使用非聚集索引，SQL会默认在此字段上创建一个聚集索

引，而主键都是唯一的，所以理所当然的认为创建聚集索引的字段也需要唯一。　

结论：聚集索引可以创建在任何一列你想创建的字段上，这是从理论上讲，实际情况并不能随便指定，否

则在性能上会是恶梦。

第二：为什么聚集索引可以创建在任何一列上，如果此表没有主键约束，即有可能存在重复行数据　　

粗一看，这还真是和聚集索引的约束相背，但实际情况真可以创建聚集索引。

分析其原因是：如果未使用 UNIQUE 属性创建聚集索引，数据库引擎将向表自动添加一个四字节 

uniqueifier 列。必要时，数据库引擎 将向行自动添加一个 uniqueifier 值，使每个键唯一。此列和列值供

内部使用，用户不能查看或访问。

第三：是不是聚集索引就一定要比非聚集索引性能优呢？　　

如果想查询学分在60-90之间的学生的学分以及姓名，在学分上创建聚集索引是否是最优的呢？

答：否。既然只输出两列，我们可以在学分以及学生姓名上创建联合非聚集索引，此时的索引就形成了覆

盖索引，即索引所存储的内容就是最终输出的数据，这种索引在比以学分为聚集索引做查询性能更好。

第四：在数据库中通过什么描述聚集索引与非聚集索引的？　

索引是通过二叉树的形式进行描述的，我们可以这样区分聚集与非聚集索引的区别：聚集索引的叶节点就

是最终的数据节点，而非聚集索引的叶节仍然是索引节点，但它有一个指向最终数据的指针。

第五：在主键是创建聚集索引的表在数据插入上为什么比主键上创建非聚集索引表速度要慢？

有了上面第四点的认识，我们分析这个问题就有把握了，在有主键的表中插入数据行，由于有主键唯一性

的约束，所以需要保证插入的数据没有重复。我们来比较下主键为聚集索引和非聚集索引的查找情况：聚

集索引由于索引叶节点就是数据页，所以如果想检查主键的唯一性，需要遍历所有数据节点才行，但非聚

集索引不同，由于非聚集索引上已经包含了主键值，所以查找主键唯一性，只需要遍历所有的索引页就行

（索引的存储空间比实际数据要少），这比遍历所有数据行减少了不少IO消耗。这就是为什么主键上创建

非聚集索引比主键上创建聚集索引在插入数据时要快的真正原因。

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

五、结合实际，谈索引使用的误区

理论的目的是应用。虽然我们刚才列出了何时应使用聚集索引或非聚集索引，但在实践中以上规则却很容

易被忽视或不能根据实际情况进行综合分析。下面我们将根据在实践中遇到的实际问题来谈一下索引使用

的误区，以便于大家掌握索引建立的方法。

1、主键就是聚集索引–错误想法的

这种想法是极端错误的，是对聚集索引的一种浪费。虽然默认是在主键上建立聚集索引的。

通常，我们会在每个表中都建立一个ID列，以区分每条数据，并且这个ID列是自动增大的，步长一般为1。如果我们将这个列设为主键，mysql会将此列默认为聚集索引。这样做有好处，就是可以让您的数据在数据库中按照ID进行物理排序，但这样做意义不大。

显而易见，聚集索引的优势是很明显的，而每个表中只能有一个聚集索引的规则，这使得聚集索引变得更

加珍贵。

从我们前面谈到的聚集索引的定义我们可以看出，使用聚集索引的最大好处就是能够根据查询要求，迅速

缩小查询范围，避免全表扫描。在实际应用中，因为 ID号是自动生成的，我们并不知道每条记录的ID号，

所以我们很难在实践中用ID号来进行查询。这就使让ID号这个主键作为聚集索引成为一种资源浪费。其次

，让每个ID号都不同的字段作为聚集索引也不符合“大数目的不同值情况下不应建立聚合索引”规则；当

然，这种情况只是针对用户经常修改记录内容，特别是索引项的时候会负作用，但对于查询速度并没有影

响。

如在办公自动化系统中，无论是系统首页显示的需要用户签收的文件、会议还是用户进行文件查询等任何

情况下进行数据查询都离不开字段的是“日期”还有用户本身的“用户名”。

通常，办公自动化的首页会显示每个用户尚未签收的文件或会议。虽然我们的where语句可以仅仅限制当

前用户尚未签收的情况，但如果您的系统已建立了很长时间，并且数据量很大，那么，每次每个用户打开

首页的时候都进行一次全表扫描，这样做意义是不大的，绝大多数的用户1个月前的文件都已经浏览过了，

这样做只能徒增数据库的开销而已。事实上，我们完全可以让用户打开系统首页时，数据库仅仅查询这个

用户近3个月来未阅览的文件，通过“日期”这个字段来限制表扫描，提高查询速度。如果您的办公自动化

系统已经建立的2年，那么您的首页显示速度理论上将是原来速度8倍，甚至更快。

在这里之所以提到“理论上”三字，是因为如果您的聚集索引还是盲目地建在ID这个主键上时，您的查询

速度是没有这么高的，即使您在“日期”这个字段上建立的索引（非聚合索引）。下面我们就来看一下在

1000万条数据量的情况下各种查询的速度表现（3个月内的数据为25万条）：

1).仅在主键上建立聚集索引，并且不划分时间段：

Select gid,fariqi,neibuyonghu,title from tgongwen

用时：128470毫秒（即：128秒）

2).在主键上建立聚集索引，在fariq上建立非聚集索引：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：53763毫秒（54秒）

3).将聚合索引建立在日期列（fariqi）上：

select gid,fariqi,neibuyonghu,title from Tgongwen

where fariqi> dateadd(day,-90,getdate())

用时：2423毫秒（2秒）

虽然每条语句提取出来的都是25万条数据，各种情况的差异却是巨大的，特别是将聚集索引建立在日期列

时的差异。事实上，如果您的数据库真的有1000 万容量的话，把主键建立在ID列上，就像以上的第1、2

种情况，在网页上的表现就是超时，根本就无法显示。这也是摒弃ID列作为聚集索引的一个最重要的因素

。得出以上速度的方法是：在各个select语句前加：

declare @d datetime

set @d=getdate()

并在select语句后加：select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())

2、只要建立索引就能显著提高查询速度–错误想法的

事实上，我们可以发现上面的例子中，第2、3条语句完全相同，且建立索引的字段也相同；不同的仅是前

者在fariqi字段上建立的是非聚合索引，后者在此字段上建立的是聚合索引，但查询速度却有着天壤之别。

所以，并非是在任何字段上简单地建立索引就能提高查询速度。

从建表的语句中，我们可以看到这个有着1000万数据的表中fariqi字段有5003个不同记录。在此字段上建

立聚合索引是再合适不过了。在现实中，我们每天都会发几个文件，这几个文件的发文日期就相同，这完

全符合建立聚集索引要求的：“既不能绝大多数都相同，又不能只有极少数相同”的规则。由此看来，我

们建立“适当”的聚合索引对于我们提高查询速度是非常重要的。

3、把所有需要提高查询速度的字段都加进聚集索引，以提高查询速度–错误想法的

上面已经谈到：在进行数据查询时都离不开字段的是“日期”还有用户本身的“用户名”。既然这两个字

段都是如此的重要，我们可以把他们合并起来，建立一个复合索引（compound index）。

很多人认为只要把任何字段加进聚集索引，就能提高查询速度，也有人感到迷惑：如果把复合的聚集索引

字段分开查询，那么查询速度会减慢吗？带着这个问题，我们来看一下以下的查询速度（结果集都是25万

条数据）：（日期列fariqi首先排在复合聚集索引的起始列，用户名neibuyonghu排在后列）：

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的

查询速度一样是因为查询的条目数一样，如果复合索引的所有列都用上，而且查询结果少的话，这样就会

形成“索引覆盖”，因而性能可以达到最优。同时，请记住：无论您是否经常使用聚合索引的其他列，但

其前导列一定要是使用最频繁的列。

六、其他书上没有的索引使用经验总结

1、用聚合索引比用不是聚合索引的主键速度快

下面是实例语句：（都是提取25万条数据）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’‘2004-9-16’’

使用时间：3326毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where gid<=250000

使用时间：4470毫秒

这里，用聚合索引比用不是聚合索引的主键速度快了近1/4。

2、用聚合索引比用一般的主键作order by时速度快，特别是在小数据量情况下

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by fariqi

用时：12936

select gid,fariqi,neibuyonghu,reader,title from Tgongwen order by gid

用时：18843

这里，用聚合索引比用一般的主键作order by时，速度快了3/10。事实上，如果数据量很小的话，用聚集

索引作为排序列要比使用非聚集索引速度快得明显的多；而数据量如果很大的话，如10万以上，则二者的

速度差别不明显。

3、使用聚合索引内的时间段，搜索时间会按数据占整个数据表的百分比成比例减少，而无论聚合索引使用

了多少个：

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’‘2004-1-1’’

用时：6343毫秒（提取100万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’‘2004-6-6’’

用时：3170毫秒（提取50万条）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi=’‘2004-9-16’’

用时：3326毫秒（和上句的结果一模一样。如果采集的数量一样，那么用大于号和等于号是一样的）

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’‘2004-1-1’’ and 

fariqi<’‘2004-6-6’’

用时：3280毫秒

4、日期列不会因为有分秒的输入而减慢查询速度

下面的例子中，共有100万条数据，2004年1月1日以后的数据有50万条，但只有两个不同的日期，日期精

确到日；之前有数据50万条，有5000个不同的日期，日期精确到秒。

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi>’‘2004-1-1’’ order 

by fariqi

用时：6390毫秒

select gid,fariqi,neibuyonghu,reader,title from Tgongwen where fariqi<’‘2004-1-1’’ order 

by fariqi

用时：6453毫秒

                                                   索引的原理

转载自：知乎 https://zhuanlan.zhihu.com/p/213772042

一、什么是索引

索引是一种利用某种规则的数据结构与实际数据的关系加快数据查找的功能；索引数据节点中有着实际文件的位置，因为索引是根据特定的规则和算法构建的,在查找的时候遵循索引的规则可以快速查找到对应数据的节点，从而达到快速查找数据的效果；其实宏观来说索引其实是一种概念而不是具体的某项技术，只是我们在某个技术中运用得比较广泛和鲜明（比如说数据库）渐渐的有了特定领域的标签，其实在生活中索引的使用无处不在，比如说：书本里的目录；读书时的座位号，考试编号都有类似索引的功能;

总结来所有通过某规则数据结构和实际目标关联，根据特定规则算法快速寻址的功能都可以称之为索引；

二、为什么要用索引

首先我们看下在没有索引的情况下是怎么查找数据的：

我们用一个例子来解释比较直观

（1）没有索引的情况下访问数据：

（2）使用平衡二叉树结构作为索引的情况下访问数据：

第一张图没有使用索引我们会进行顺序查找，依照数据顺序逐个进行匹配，进行了5次寻址才查询出所需数据，第二张图用了一个简单的平衡二叉树索引之后我们只用了3次，这还是数据量小的情况下，数据量大了效果更明显，所以总结来说创建索引就是为了加快数据查找速度；

三、Innodb 的索引选择

Mysql 的默认存储引擎innodb使用B+树作为索引的存储结构，为了让我们能更深入理解B+树，所以我们会对B+树的衍生过程做一些了解。

1、数组和链表的选择

作为最基础的数据存储结构数组和链表，是选用数组还是选择链表来作为索引存储的基本结构呢？首先我们需要从索引和两种数据结构的特性来分析。

数组的特性： 查找快、但是插入、修改数据慢。

链表的特性： 查找慢、插入、修改快。

在数据库的业务场景里插入、修改、查询都是比较频繁的操作，选链表还是数组好像都不完美。既然都不完美，那么我们只能退而求其次，看谁比较容易去完善。从完善的角度来看，那么我们就会从数组里发现一个致命的问题，数组的修改和移动都会导致数组大量的元素迁移，而且在迁移的过程中是不能查找数据的，数组元素迁移没有完成查询出来的数据就可能是错的，这样就导致数组在频繁插入和修改的过程中不仅仅是修改和插入本身慢，而且因为这个而导致查询也用不了，显然这个问题对于修改和插入频繁的数据库来说是无法忍受的。所以我们只能把链表作为索引的基础结构了，那么剩下的就是如何解决链表查询小笼包慢的问题了。

2、从链表到二叉树

如果使用链表来存储数据，那么必须要解决的一个问题就是要解决链表的查询效率问题，我们必须通过一种算法来解决链表查找数据慢的问题，而这里这里就用到了二分查找法，利用二分法思维把链表拆成N个对半分的节点，然后形成了一个数据结构叫二叉查找树，使用了二分法思维衍生出来的树大大提升了查找的性能。

3、从二叉查树到平衡二叉树

二叉查找树极大的提升了链表查找数据的效率，不过我们又发现了一个问题，就是二叉查找树的“高度”不可控，一旦树的节点插入变成向下图一样的结构。

如果树的节点不可控编程变成线性结构，那么就会极大的降低我们的查询效率，所以我们就又需要一种算法来保证二叉树节点的平衡，让树的节点高度差不会太大，这个时候就衍生了一些平衡算法，最终我们的二叉树就有像AVL树和红黑树这些新产品，我们也称这些新产品为平衡二叉树，，平衡二叉树通常会保证树的左右两边的节点层级相差不会大于2。

4、从平衡二叉树到B树

平衡二叉树的出现好像很接近于我们的理想状态了，但好像还有什么优化的空间，我们通过上面两个树的演化过程发现，影响这棵树的查询效率的决定性因素就是树的高度，只要树的层级越少，那么树的查询效率就越高，本着这个原则我们就思考每个节点能不能多存点 数据，只要每个数节点的数据保存的越多，那么我们树的层级就会越少，

B树相对平衡二叉树最大的一个改变，就是B树的每个节点可存储的关键字增多了，特别是在B树应用到数据库中的时候，节点存储关键字的数量充分利用了磁盘块IO的原理（磁盘数据存储是采用块的形式存储的，每个块的大小为4K，每次IO进行数据读取时，同一个磁盘块的数据可以一次性读取出来），B树只要把节点大小限制在磁盘快大小范围，这样就可以只需要一次IO就读取到节点所有数据，节点存储了更多的关键字，但是并不会影响IO的次数。B树树相对于之前节点可以存储更多的关键字，所以树的层级会比原来少很多，树的层级减少了，那么检索的效率就会大大提升。

5、从B树到B+树

其实B树已经接近我们的理想预期了，但是还是能从B树的上面找到可以优化的地方，比如以下几个方面：

1、B树的节点同时保存了索引的key和数据值（如果节点只保存索引key不保存值，那么是不是会把索引树的层层级更进一步的减少）。

2、因为每个节点保存了数据值，这样的话查询不同的数据效率就会显得不稳定，有些在树的第一层匹配成功就返回，有些则可能需要匹配到树的最后一层才返回。

3、如果要查询所有数据，那么就必须遍历整个B树的每个节点。

B+树在B树的基础上 又做了一些优化，B+树主要做了下面几点的优化。

1、B+跟B树不同，B+树的非叶子节点不保存实际的数据，只保存索引key，所有的数据都会保存到叶子节点。

树层级变少：如果非叶子节点不保存实际的数据值，而只保存索引key，那么相对于B树来说B+树的每个非叶子节点存储的索引key会更多，所以树的层级也会更少，那么查询效率也会更快。

查询更稳定：因为B+所有数据值都是存在叶子节点上，所以每次查找的次数都相同所以查询速度要比B树更稳定；

遍历整个树更快：B+树遍历整棵树只需要遍历所有的叶子节点即可，，而不需要像B树一样需要对每一层进行遍历，这有利于数据库做全表扫描。

2、B+树叶子节点的关键字从小到大有序排列，左边结尾数据都会保存右边节点开始数据的指针。

排序和范围查询更方便：B+树所有的叶子节点数据构成了一个有序链表，这样在进行数据排序和询范围大小查询数据的时候更方便，数据紧密性也更高。

（百度百科算法结构示意图）

总结来说，从平衡二叉树、B树、B+树，总体来看它们的贯彻的思想是相同的，在链表的基础上，如何采用二分法和数据平衡策略来提升查找数据的速度。不同点是他们一个一个在演变的过程中通过IO从磁盘读取数据的原理进行一步步的演变，每一次演变都是为了让节点的空间更合理的运用起来，从而使树的层级减少达到快速查找数据的目的，在这个基础上，B+树的查找速度快、性能稳定、排序快、扫表快等诸多特点也就让Mysql选择了B+树来作为索引的存储结构。

四、补充

为什么说Mysql的索引树一般都在1-3层的结构？

经常听到别人说Mysql的索引树一般会在3层，这个是有什么依据？ 其实这个的确是有数据计算支撑的，我们可以根据B+树的原理进行一下数据推算，因为磁盘每页数据为4K，而Mysql的B+树对此又进行了一次调整，在Mysql也有自己的页概念，Mysql里的每一页数据等于磁盘4个页的大小，所以在Mysql里面的一页数据其实是16K，那么也就意味着Mysql里B+树的非叶子节点可存储16K的数据。

然后我们按照一个索引大小，如果字段类型为varchar，长度为10，字符类型为utf8mb4，在不考虑其他因素的影响下，一个索引的大小等于 10 3+2=32字节，我们按照每个非叶子节点的16K来计算，Mysql索引树每个节点能容纳(161024)/32=512个索引key。

索引树的第一层：第一层是树的根节点，所以索引树的第一层保存索引Key的数量为512个；

索引树的第二层：B+树根节点可保存512个索引key，也就是当前B+树有512个分叉，那么第二层索引树节点个数为512个，保存索引Key的数量=512*512=262144。

索引树的第三层：第二层key数量为262144，那么第三层的树节点数量也就是262144，那么第三层索引树节点个数为512个，保存索引Key的数量=262144*512=134217728。

根据一个计算我们可以基本得出，类型varchar，长度为10，字符类型为utf8mb4的索引字段，数据在512条之内树结构只有一层。数据在262144之内树只有两层，数据在134217728之内，索引树都会保持在3层之内，而我们的表数据一般而言都保持在千万级以内，所以说Mysql的索引树一般都在1-3层。

                                          详解索引和视图

转载自：https://zhuanlan.zhihu.com/p/639914332?utm_id=0

一、索引

1.1 什么是索引

索引就是数据表中数据和相应的存储位置的列表，利用索引可以提高在表或视图中的查找数据的速度。它类似于书籍的索引，可以帮助快速定位和检索数据。在数据库中，索引是对一个或多个列的值进行排序和存储的结构，它们包含指向实际数据位置的指针。

1.2 索引分类

数据库中索引主要分为两类：聚集索引和非聚集索引。SQL Server 还提供了唯一索引、索引视图、全文索引、XML 索引等等。聚集索引和非聚集索引是数据库引擎中索引的基本类型，是理解其他类型索引的基础。

1.2.1 聚集索引

聚集索引是值表中数据行的物理存储顺序和索引的存储顺序完全相同。聚集索引根据索引顺序物理地重新排列了用户插入到表中的数据，因此，每个表只能创建一个聚集索引。聚集索引经常创建在表中经常被搜索到的列或按顺序访问的列上。在默认情况下，主键约束自动创建聚集索引。

1.2.2 非聚集索引

非聚集索引不改变表中数据列的物理存储位置，数据与索引分开存储，通过索引指向的地址与表中的数据发生关系。

非聚集索引没有改变表中物理行的位置，索引可以在以下情况下使用非聚集索引：

• 如果某个字段的数据唯一性比较高

• 如果查询所得到的数据量比较少

1.2.3 聚集索引和非聚集索引的区别

这里用一个表格简单的总结一下聚集索引和非聚集索引的区别：

1.2.4 其他类型索引

除了以上索引，还有以下类型索引：

• 唯一索引：如果希望索引键都不同，可以创建唯一索引。聚集索引和非聚集索引都可以是唯一索引。

• 包含新列索引：索引列的最大数量是16个，索引列的字节总数的最高值是900。如果当多个列的字节总数大于900，切又想在这些劣种都包含索引是，可以使用包含新列索引

• 视图索引：提供视图查询效率，可以视图的索引物理化，也就是说将结果集永久存储在索引中，可以创建视图索引。

• XML索引：是与xml数据关联的索引形式，是XML二进制blob的已拆分持久表示形式

• 全文索引：一种特殊类型的基于标记的功能性功能，用于帮助在字符串中搜索赋值的词

1.3 创建索引

1.3.1 语法

create [unique] [clustered | noclustered]
index index_name
on table_name (column_name ...)
[with fillfactor=x]

参数解释

unique 唯一索引
         clustered 聚集索引
         noclustered 非聚集索引
         fillfactor 填充因子大小，范围在 0-100 直接，表示索引页填满的空间所占的百分比。

1.3.2 创建索引的命名规则最佳实践

在 MSSQL 中，索引的命名规则的最佳实践可以有一些常见的准则，以提高可读性和维护性。这个潜在的要求不仅试用于 SQL Server 数据库，同样在其他数据库例如 MySQL、Oracle 中都同样值得注意。

下面是个人总结的一些命名规则与建议：

1. 命名应该具有描述性：索引的名称应该能够清晰地表达其作用和关联的列或表。使用有意义的名称可以使其他开发人员更容易理解索引的用途。

2. 包含表名和列名：在索引名称中包含相关表名和列名（长表名可适当缩写，但要确保可以定位到表），可以使索引更具可读性，并且可以避免在不同表之间使用相同名称的索引时的冲突。

3. 使用统一的命名约定：为了提高一致性，可以定义一套命名约定，并在整个数据库中使用。例如，可以使用特定的前缀或后缀来标识索引的类型（如 idx_ 表示非聚集索引）。

4. 避免过长的名称：索引名称不应该过长，以免在使用索引时引起不便。尽量使用简洁但描述性的名称。

5. 避免使用保留关键字和特殊字符：确保索引名称不与 MSSQL 的保留关键字或特殊字符冲突，以避免语法错误。

1.3.3 创建索引示例

-- 普通索引
if (exists (select * from sys.indexes where name = 'idx_stu_name'))
 drop index student.idx_stu_name
go
create index idx_stu_name
on
student(name);
-- 联合索引
if (exists (select * from sys.indexes where name = 'idx_uqe_clu_stu_name_age'))
 drop index student.idx_uqe_clu_stu_name_age
go
create unique clustered index idx_uqe_clu_stu_name_age
on student(name, age);
if (exists (select * from sys.indexes where name = 'idx_cid'))
 drop index student.idx_cid
go
if (exists (select * from sys.indexes where name = 'idx_cid'))
 drop index student.idx_cid
go
-- 非聚集索引
create nonclustered index idx_cid
on
student (cid)
with fillFactor = 30; --填充因子
-- 聚集索引
if (exists (select * from sys.indexes where name = 'idx_sex'))
 drop index student.idx_sex
go
create clustered index idx_sex
on
student(sex);
-- 聚集索引
if (exists (select * from sys.indexes where name = 'idx_name'))
 drop index student.idx_name
go
create unique index idx_name
on
student(name);

1.4 适合的创建索引的列

一般情况，可以选择那些对查询性能有积极影响的列进行索引创建，下面进行一定的总结：

列的选择性：选择性是指列中不同值的数量与总行数的比例。如果某列具有较高的选择性，即不同的值较多，那么为该列创建索引可能会有更好的效果。例如，在表示性别的列上创建索引可能没有太大的帮助，因为只有两个可能的值。

查询频率：观察经常用于查询条件的列。如果某个列经常用于搜索、过滤或连接操作，那么为该列创建索引可以提高查询性能。

数据表的大小：对于大型表，创建索引的影响可能更加显著。较小的表可能不需要太多的索引，因为全表扫描的开销相对较小。

数据更新频率：索引的创建和维护也会增加对数据的写操作的开销。如果某个列的数据经常发生变化，那么创建索引可能会带来一定的性能开销。

查询性能优化需求：通过分析查询执行计划，可以确定是否存在潜在的性能瓶颈，并考虑为相关的列创建索引以改善查询性能。

请注意过多的索引也可能会带来维护开销和存储成本，因此需要在权衡索引数量和性能提升之间找到平衡点。定期监控和评估索引的使用情况也是重要的，以确保索引仍然对数据库性能产生积极影响。

1.5 不适合创建索引的列

虽然在某些情况下创建索引可以提高查询性能，但并不是所有列都适合创建索引。以下是一些不适合创建索引的列的情况：

低选择性列：如果某个列的选择性很低，即该列的不同值较少，创建索引可能不会带来明显的性能提升。例如，对于性别这样只有几个可能值的列，创建索引可能不会有太大意义。

经常更新的列：如果某个列的值经常被修改，那么为该列创建索引可能会带来额外的维护成本和性能开销。每次更新操作都需要更新索引，这可能会影响写入性能。在这种情况下，需要仔细评估是否真的需要为该列创建索引。

过于频繁的查询列：某些列可能经常被查询，但它们的选择性较低，即不同的值较少。在这种情况下，尽管查询频率高，但为该列创建索引可能不会带来明显的性能提升，因为索引的使用效果有限。

大文本或大二进制列：对于存储大文本或大二进制数据的列，如长文本字段或图像字段，创建索引的效果通常较差。这是因为索引本身需要占用额外的存储空间，并且对于大型数据的索引操作可能变得非常耗时。

不常用的列：对于很少用于查询的列，创建索引可能没有太大意义。如果一个列很少用于查询条件或连接操作，那么为其创建索引可能只会增加额外的开销而不带来实际的性能提升。

需要注意的是，以上列举的情况只是一般性的指导原则，具体是否适合创建索引还取决于具体的数据库结构、查询模式和性能需求。在设计和创建索引时，应根据具体情况进行评估，并进行性能测试和优化以确保索引的有效性。

二、视图

2.1 什么是视图

视图就是一个虚拟的数据表，该数据表中的数据记录是由一条查询语句的查询结果得到的。

2.2 为什么要使用视图，而不是表（面试可能会被问到）

如果你在面试的时候被问到这个问题，建议从下面这个流程来回答一下面试官。

首先介绍一下表的作用（比如表是直接存储结构化数据，可以扩展增删改之类的），之后在介绍一下视图是什么，之后从两个切入点来讲解视图的好处以及必要性，这两个切入点是：复用性和安全性，这里来简单总结一下：

1. 简化查询，提高复用性
   想象一下，一个人员宽表，里面有几百个字段，但是你每次只需要用到这个表中的姓名、性别、年龄这三个字段，那么你可以创建一个视图来直接使用，或者你这个人员表经常和另外一个履历表 join 组合在一起，而只取了其中的部分字段，并且频繁使用这几个字段。那么无疑创建视图是一个好做法。当然这种情况也可以说明使用视图能够简化查询。

2. 提高安全性

• 通过视图，可以限制用户对敏感数据的直接访问。视图可以控制用户可以看到和操作的数据的范围，提供更好的安全性和隐私保护。这里还拿刚才我讲的姓名、性别、年龄三个字段，假如年龄是一个比较敏感的字段，那么对某些数据库用户只能查询姓名和性别的话，那么就可以设置一个视图分配给这个用户。

• 另外就是如果你要更新视图的时候，也只能更新视图所见的字段，用户对视图不可以随意的更改和删除，可以一定程度的保证数据的安全性。

讲解完上述的两个大的关键点后，也可以适当自行发挥，比如视图你可以调整表字段的显示顺序，或者字段名字等等。这些也是优点。可以适当进行讲解。

2.3 创建视图

创建视图的时候，对命名视图大家一般也有默认的规则，一般情况可以使用 v_ 或 view_ + 表名（表缩写）的形式。

例如：v_student

--创建视图
if (exists (select * from sys.objects where name = 'v_student'))
 drop view v_student
go
create view v_student
as
select id, name, age, sex from student;

2.4 创建视图准则

创建视图需要考虑一下准则：

1. 视图名称必须遵循标识符的规则，该名称不得与该架构的任何表的名称相同。

2. 你可以对其他视图创建视图。允许嵌套视图，但嵌套不得超过32层。视图最多可以有1024个字段。

3. 不能将规则和 default 定义于视图相关联。

4. 视图的查询不能包含 compute 子句、compute by 子句或 into 关键字。

5. 定义视图的查询不能包含 order by 子句，除非在 select 语句的选择列表中还有 top 子句。

下列情况必须指定视图中每列的名称：

• 有列顺序需求（在某些情况下，您可能希望定义视图的结果集中列的顺序，并且这与基础表中的顺序不同。）

• 视图中的任何列都是从算术表达式、内置函数或常量派生而来

• 视图中有两列或多列具有相同名称（通常由于视图定义包含联接，因此来自两个或多个不同的列具有相同的名称）

• 有指定列别名的需求。注意无论是否重命名，视图列都需继承原列的数据类型

2.5 修改视图

修改视图和修改表有点类似，可以直接使用 alter 关键字进行修改，示例如下：

alter view v_student
as
select id, name, sex from student;
alter view v_student(编号, 名称, 性别)
as
 select id, name, sex from student
go
select * from v_student;
select * from information_schema.views;

2.6 加密视图

如果你对某一个视图有保护查询逻辑、防止修改或者查询加密的需求的时候，可以使用加密视图操作。

在 SQL Server 中 使用with encryption后，可以在创建视图时对其定义的 SQL 查询进行加密。也就是说 MSSQL 会对该视图的定义中的查询语句进行加密。这意味着其他人无法直接查看或分析该视图的查询逻辑。压根就看不到这个视图内部结构了。

-- 加密视图
if (exists (select * from sys.objects where name = 'v_student_info'))
 drop view v_student_info
go
create view v_student_info
with encryption --加密
as
 select id, name, age from student
go
--view_definition is null
select * from information_schema.views 
where table_name like 'v_student';

如何解密被加密的视图，或者修改已经被加密的视图：

一般情况一个视图被加密后，你需要修改它，那么大致有3个方法：

1. 重新创建视图（先删除已加密的视图，然后使用新的查询逻辑重新创建视图。）。

2. 创建新视图（创建一个新的，视图名称不同，之后调用这个新的）。

3. 暴力解密之后修改（一般需要借助第三方工具或辅助，该方式个人不推荐）

2.7 视图能否被更新 update （面试可能会被问到）

视图可以被更新吗？什么情况下可以被更新？

如果面试官问了这两个问题，那么他还算友好的提醒了你，如果直接问了一句话“视图可以被更新吗？”，那么我感觉有被挖坑的嫌疑。

视图可以被更新，但不是所有的情况都可以。

视图更新必须遵循以下规则：

1. 当视图的字段是通过字段表达式（Field Expression）或常数（Constant）计算得出的结果时，对该视图执行 INSERT 和 UPDATE 操作是不允许的，但可以执行 DELETE 操作。

2. 若视图的字段是来自库函数，则此视图不允许更新；

3. 若视图的定义中有 GROUP BY 子句或聚集函数时，则此视图不允许更新；

4. 若视图的定义中有 DISTINCT 任选项，则此视图不允许更新；

5. 若视图的定义中有嵌套查询，并且嵌套查询的 FROM 子句中涉及的表也是导出该视图的基表，则此视图不允许更新；

6. 若视图是由两个以上的基表导出的，此视图不允许更新（源表单一才可以被更新）；

7. 一个不允许更新的视图上定义的视图也不允许更新；

8. 由一个基表定义的视图，只含有基表的主键或候补键，并且视图中没有用表达式或函数定义的属性，才允许更新。

                    视图的操作

转载自：https://www.jianshu.com/p/a03cbcc0ec9b

一、视图 view

在查询中，我们经常把查询结果，当成临时表来看。

view就可以看成是一张虚拟的表。是表通过某种运算得到的一个投影。

1.1 引出视图

场景1：

现要求查询每个栏目下，商品的平均价格，并取平均价前3高的栏目。

解法1：不知道视图的情况下
求得平均价格，然后group_by cat_id ，然后order by avg，然后limit再取前3条。

场景2：

要取平均价格由高到低，第3到第5名的栏目

场景3：

查出前3低的栏目。上面两种情况，都要用到临时的结果集A。

对于上面两个场景，为了方便，我们想到把临时的结果集A存储到内存中，方便以后查询。

难点：

如果过一段时间，又添加了几个商品，价格很高或很低，影响到了平均价格。那么A的结果集与前面保存的表的结果就不一样了，这时候应该怎么办？

用视图来解决。

1.2、视图

1.2.1 创建视图

视图中没有真实数据，就是表通过运算得到的投影（表发生变化的时候，视图也就会发生相应的变化）

问：如何创建视图？
问：建立视图的时候，我们需要指定视图的列名与列类型吗？
答：不需要，视图只是表的影子，继承了上面表的字段。

既然视图只是表的某种查询的投影，所以主要步骤在查询表上。
查询的结果命名为视图就可以了。

1.2.2 创建视图语法

create view 视图名
       as
       select 语句

1.3 用视图解决上面的问题

1.3.1 创建视图stats

相对于上面的例题，我们创建一个平均价格的视图stats。

这时候，show tables ，发现多了一个table，就是stats。然后查看stats中的数据：

就跟我们刚才创建的那个临时结果集A是一样的。（但是这个只是投影，并不是实实在在的数据）

1.3.2 利用视图查询得到结果

视图一旦创建完毕，就可以当做一个表了。比如这里我们查询前3高的平均价格cat_id。

1.4 视图的作用：

1、可以简化我们的查询

比如，复杂的统计时，先用视图生成一个中间结果，再查询视图。

2、更精细的权限控制

以表为例。两个网站搞合作，可以查询对方网站的用户，需要向对方开放用户的权限，但是又不想开放用户表中的密码字段。应该怎么解决？

可以创建一个视图，包含所有的字段，但是就不包含密码字段，然后开放视图的权限给对方。

3、数据多，分表时可以用到

比如说，有小说站，小说存储在novel表中，1000多万篇。数据分别存储在novel1，novel2，novel3，novel4，novel5中。查询小说时，不知道在哪张表，怎么办？

这时候可以用union连接把所有的表都连接起来，并把结果当做一个视图，然后在这个视图中查询。（就不需要在每个表中查询一次了）

1.5 表与视图变化之间的相互影响

1.5.1 表变化，视图会怎样？

比如对于当前视图stats：

此时查询15号栏目下的商品，发现stats中的平均价格是正确的。

此时我们如果改变good的一个价格good1，

发现视图中的平均价格也随之改变了。

stats1

表变化，视图会随之改变。

1.5.3 情况1

对于上面的视图stats1中，cat_id=15的情况，如果我们把平均价格pj改成了90，那么此时表会不会变？
应该不会变，因为视图是根据表good1来的，平均值多了10，反推过去，你是没法确定原来的两个good价格95与65是怎样修改导致平均值增加的。

1.5.4 情况2

这张视图，数据表示的是最贵的5个商品。那么此时视图能不能改呢？

此时，增、删、改也是不能实现的。（详情可以观看p39）

疑问：那么视图到底能否修改呢？

1.5.5 情况3

我们创建一个视图，是cat_id=4的栏目商品的投影，然后试着对视图做修改。

执行删除操作：

我们发现good_id=1的商品被删除掉了，然后表中的商品也被删掉了。

1.5.6、总结

于是，我们得出结论，在某种情况下，视图也是可以修改的。
         修改条件：视图的数据跟表的数据一一对应，就像函数的映射。由表中数据能对应到视图，由视图能对应到表。

具体能不能修改的情况，可以去看手册。比如order by limit就不能修改。

1.6、视图占用空间吗

视图的定义是一直存在的，但是视图是不占用空间的，里面并不存储数据。

删除视图，跟删除表的语法是一样的。