索引是与表或视图关联的磁盘上结构，可以加快从表或视图中检索行的速度。索引包含由表或视图中的一列或多列生成的键。这些键存储在一个结构(B 树)中，使 SQL Server 可以快速有效地查找与键值关联的行。
表或视图可以包含以下类型的索引：
聚集索引
聚集索引根据数据行的键值在表或视图中排序和存储这些数据行。索引定义中包含聚集索引列。每个表只能有一个聚集索引，因为数据行本身只能按一个顺序排序。
只有当表包含聚集索引时，表中的数据行才按排序顺序存储。如果表具有聚集索引，则该表称为聚集表。如果表没有聚集索引，则其数据行存储在一个称为堆的无序结构中。
每个表几乎都对列定义聚集索引来实现下列功能：
1、可用于经常使用的查询。
2、提供高度唯一性。
在创建聚集索引之前，应先了解数据是如何被访问的。考虑对具有以下特点的查询使用聚集索引：
使用运算符(如 BETWEEN、>、>=、< 和 <=)返回一系列值。
使用聚集索引找到包含第一个值的行后，便可以确保包含后续索引值的行物理相邻。例如，如果某个查询在一系列采购订单号间检索记 录，PurchaseOrderNumber 列的聚集索引可快速定位包含起始采购订单号的行，然后检索表中所有连续的行，直到检索到最后的采购订单号。
返回大型结果集。
使用 JOIN 子句;一般情况下，使用该子句的是外键列。
使用 ORDER BY 或 GROUP BY 子句。
在 ORDER BY 或 GROUP BY 子句中指定的列的索引，可以使数据库引擎 不必对数据进行排序，因为这些行已经排序。这样可以提高查询性能。
聚集索引不适用于具有下列属性的列：
频繁更改的列
这将导致整行移动，因为数据库引擎 必须按物理顺序保留行中的数据值。这一点要特别注意，因为在大容量事务处理系统中数据通常是可变的。
宽键
宽键是若干列或若干大型列的组合。所有非聚集索引将聚集索引中的键值用作查找键。为同一表定义的任何非聚集索引都将增大许多，这是因为非聚集索引项包含聚集键，同时也包含为此非聚集索引定义的键列。 非聚集索引
非聚集索引具有独立于数据行的结构。非聚集索引包含非聚集索引键值，并且每个键值项都有指向包含该键值的数据行的指针。
从非聚集索引中的索引行指向数据行的指针称为行定位器。行定位器的结构取决于数据页是存储在堆中还是聚集表中。对于堆，行定位器是指向行的指针。对于聚集表，行定位器是聚集索引键。
在 SQL Server 2005 中，可以向非聚集索引的叶级别添加非键列以跳过现有的索引键限制(900 字节和 16 键列)，并执行完整范围内的索引查询。
非聚集索引与聚集索引具有相同的 B 树结构，它们之间的显著差别在于以下两点：
1、基础表的数据行不按非聚集键的顺序排序和存储。
2、非聚集索引的叶层是由索引页而不是由数据页组成。
设计非聚集索引时需要注意数据库的特征:
更新要求较低但包含大量数据的数据库或表可以从许多非聚集索引中获益从而改善查询性能。
决策支持系统应用程序和主要包含只读数据的数据库可以从许多非聚集索引中获益。查询优化器具有更多可供选择的索引用来确定最快的访问方法，并且数据库的低更新特征意味着索引维护不会降低性能。
联机事务处理应用程序和包含大量更新表的数据库应避免使用过多的索引。此外，索引应该是窄的，即列越少越好。
一个表如果建有大量索引会影响 INSERT、UPDATE 和 DELETE 语句的性能，因为所有索引都必须随表中数据的更改进行相应的调整。
唯一索引
唯一索引确保索引键不包含重复的值，因此，表或视图中的每一行在某种程度上是唯一的。
聚集索引和非聚集索引都可以是唯一索引。
包含性列索引
一种非聚集索引，它扩展后不仅包含键列，还包含非键列。
索引涵盖
指查询中的SELECT与WHERE子句的所用列同时也属于非聚集索引的情况。这样就可以更快检索数据，因为所有信息都可以直接来自于索引页，从而SQL Server可以避免访问数据页。加上独立的索引文件组，可以用最快速度访问数据。
请看如下表示例：
A.创建简单非聚集索引 以下示例为 Purchasing.ProductVendor 表的 VendorID 列创建非聚集索引。
| USE AdventureWorks; GO CREATE INDEX IX_ProductVendor_VendorID ON Purchasing.ProductVendor (VendorID); GO |
B. 创建简单非聚集组合索引
以下示例为 Sales.SalesPerson 表的 SalesQuota 和 SalesYTD 列创建非聚集组合索引。
| CREATE NONCLUSTERED INDEX IX_SalesPerson_SalesQuota_SalesYTD ON Sales.SalesPerson (SalesQuota, SalesYTD); GO |
C. 创建唯一非聚集索引
以下示例为 Production.UnitMeasure 表的 Name 列创建唯一的非聚集索引。该索引将强制插入 Name 列中的数据具有唯一性。
| USE AdventureWorks; GO CREATE UNIQUE INDEX AK_UnitMeasure_Name ON Production.UnitMeasure(Name); GO |
无论何时对基础数据执行插入、更新或删除操作，SQL Server 2005
数据库引擎都会自动维护索引。随着时间的推移，这些修改可能会导致索引中的信息分散在数据库中(含有碎片)。当索引包含的页中的逻辑排序(基于键值)与数
据文件中的物理排序不匹配时，就存在碎片。碎片非常多的索引可能会降低查询性能，导致应用程序响应缓慢。这个时候，我们需要做得就是重新组织和重新生成索
引。重新生成索引将删除该索引并创建一个新索引。此过程中将删除碎片，通过使用指定的或现有的填充因子设置压缩页来回收磁盘空间，并在连续页中对索引行重
新排序(根据需要分配新页)。这样可以减少获取所请求数据所需的页读取数，从而提高磁盘性能。
可以使用下列方法重新生成聚集索引和非聚集索引：
带 REBUILD 子句的 ALTER INDEX。此语句将替换 DBCC DBREINDEX 语句。
带 DROP_EXISTING 子句的 CREATE INDEX。
示例如下：
A. 重新生成索引
GO
ALTER INDEX PK_Employee_EmployeeID ON HumanResources.Employee
REBUILD;
GO
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON);
GO
图:典型的B*树索引布局
这个树底层的块称为叶子节点(leaf node) 或(leaf
block),其中分别包含各个索引键以及一个rowid(它是指向所索引的行)。叶子节点之上的内部块称为分支块(branch
block)，这些节点用于实现导航。例如，如果想在索引中找到值20，要从树顶开始，找到左分支，我们检查这个块，并发现需要找到范围"20..25"
的块，这个块将是叶子块，其中会指示包含数20的行。索引的叶子节点实际上构成了一个双向链表。一旦发现要从叶子节点中的那里开始，执行值的有序扫描
(index range scan)就会很容易，我们就不必再在索引结构中导航：而只需根据叶子节点向前或向后扫描就可以了。
B*树的特点之一是：所有叶子块都应该在树的同一层上，这一层称之为索引的高度,
它说明所有从索引的根块到叶子块的遍历都会访问同样数目的块。也就是说，对于形如"SELECT INDEX_column FROM TABLE
WHERE INXDEX_column
=:X"的索引，要达到叶子块来获取第一行，不论使用的:X值是什么，都会执行同样数目的I/O,由此可见B*树的B代表的是balanced，所谓
的"Height
balanced"。大多数B*树索引的高度都是2或3，即使索引中有数百万行记录也是如此，这说明，一般而言，在索引中找到一个键只需要2到3次I/O
, 这确实不错。
B*树是一个极佳的通用索引机制，无论是大表还是小表都很适用，随着底层表大小增长，获取数据的性能仅会稍有恶化。
比如，我们为customers表建立一个常见的B*树索引:
| CREATE INDEX IDX_Cus_City on customers(city) |
B*树索引有以下子类型：
复合索引
复合索引也是一种B*树索引,它由多列组成。当我们拥有使用两列或超过两列的频繁查询时，就使用B*树复合索引，而其所使用的两列或多列在
where子句中and逻辑操作符连接。因为复合索引中列的顺序很重要，所以确信以最有效的索引能排列他们，可以参考用作列排序的下面的两个准则 ：
1) 前导列应该是查询中使用最频繁的列。
2) 前导列应该是选择最多的列，这意味着它比后面的列具有更高的基数。
复合索引在下列情况中具有优势：
1)假定在WHERE子句中频繁使用下面的条件：order_status_id = 1 和order_date =
‘dd-mon-yyyy’。如果为每一列创建一个索引，那么为了搜索列的值，两个索引都要被读取，但是如果为两列都创建一个复合索引，那么只有一个索引
被读取，这样无疑比两个索引要求更少的I/O。
2) 使用前面例子中同样的条件，如果创建一个复合索引，将更快地检索行，因为你正在排除了所有order_status_id 不是1的行，从而减少了搜索order_date的行数。
反向键索引
B*树索引的另一个特点是能够将索引键“反转”。首先，你可以问问自己“为什么想这么做?”
B*树索引是为特定的环境、特定的问题而设计的。实现B*树索引的目的是为了减少“右侧”索引中对索引叶子块的竞争，比如在一个Oracle RAC
环境中，某些列用一个序列值或时间戳填充，这些列上建立的索引就属于“右侧”(right-hand-side)索引。
RAC 是一种Oracle
配置，其中多个实例可以装载和打开同一个数据库。如果两个实例需要同时修改同一个数据块，它们会通过一个硬件互连(interconnect)来回传递这
个块来实现共享，互连是两个(或多个)机器之间的一条专用网络连接。如果某个利用一个序列填充，这个列上有一个主键索引
，那么每个人插入新值时，都会视图修改目前索引结构右侧的左块(见本文图一，其中显示出索引中较高的值都放在右侧，而较低的值放在左侧)。如果对用序列填
充的列上的索引进行修改，就会聚集在很少的一组叶子块上。倘若将索引的键反转，对索引进行插入时，就能在索引中的所有叶子键上分布开(不过这往往会使索引
不能得到充分地填充)。
反向键索引创建语句语法如下：
| CREATE INDEX index_name on table_name(column_name) REVERSE ; |
降序索引
降序索引(descending index)是oracle 8i引入的，用以扩展B*树索引的功能，它允许在索引中以降序(从大到小的顺序)存储一列。在oracle8i及以上版本中，DESC关键字确实会改变创建和使用索引的的方式。
我们可以这样创建降序索引
| CREATE INDEX IDX_jobs_title on hr.jobs (job_title DESC); SET autotrace traceonly EXPLAIN; SELECT * FROM hr.jobs WHERE job_title Between 'a' AND 'ZZZZZZZZZZZ '; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=1 Card=1 Bytes=33) 1 0 FILTER 2 1 TABLE ACCESS (BY INDEX ROWID) OF 'JOBS' (Cost=1 Card=1 B ytes=33) 3 2 INDEX (RANGE SCAN) OF 'IDX_JOBS_TITLE' (NON-UNIQUE) (C ost=2 Card=1) SQL> SELECT * from hr.jobs 2 WHERE job_title between 'a' and 'ZZZZZZZZZZZ '; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=33) 1 0 FILTER 2 1 TABLE ACCESS (FULL) OF 'JOBS' (Cost=2 Card=1 Bytes=33) SQL> DROP INDEX IDX_jobs_title ; SQL> CREATE INDEX IDX_jobs_title on hr.jobs (job_title ); SQL> Select * FROM hr.jobs 2 Where job_title between 'a' and 'ZZZZZZZZZZZ '; Execution Plan ---------------------------------------------------------- 0 SELECT STATEMENT Optimizer=CHOOSE (Cost=2 Card=1 Bytes=33) 1 0 FILTER 2 1 TABLE ACCESS (FULL) OF 'JOBS' (Cost=2 Card=1 Bytes=33) |
位图索引
位图索引(bitmap index)是从Oracle7.3
版本开始引入的。目前Oracle企业版和个人版都支持位图索引，但标准版不支持。位图索引是为数据仓库/在线分析查询环境设计的，在此所有查询要求的数
据在系统实现时根本不知道。位图索引特别不适用于OLTP 系统，如果系统中的数据会由多个并发会话频繁地更新，这种系统也不适用位图索引。
位图索引是这样一种结构，其中用一个索引键条目存储指向多行的指针;这与B*树结构不同，在B*树结构中，索引键和表中的行存在着对应关系。在位图索引中，可能只有很少的索引条目，每个索引条目指向多行。而在传统的B*树中，一个索引条目就指向一行。
B*树索引一般来讲应当是选择性的。与之相反，位图索引不应是选择性的，一般来讲它们应该“没有选择性“。如果有大量在线分析查询，特别是查询
以一种即席方式引用了多列或者会生成诸如COUNT 之类的聚合，在这样的环境中，位图索引就特别有用 。位图索引使用 CREATE BITMAP
INDEX index_name ON table_name(column_name1,column_name2) TABLESPACE
tablespace_name命令语法创建。
SQL Server查询优化技术及索引
From: http://www.cnblogs.com/lovewindy/archive/2005/02/19/105959.html
在《数据库原理》里面，对聚簇索引的解释是:聚簇索引的顺序就是数据的物理存储顺序，而对非聚簇索引的解释是:索引顺序与数据物理排列顺序无关。正式因为如此，所以一个表最多只能有一个聚簇索引。
不过这个定义太抽象了。在SQL Server中，索引是通过二叉树的数据结构来描述的，我们可以这么理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索引的叶节点仍然是索引节点，只不过有一个指针指向对应的数据块。如下图：
非聚簇索引
聚簇索引
聚簇索引与非聚簇索引的本质区别到底是什么？什么时候用聚簇索引，什么时候用非聚簇索引？
这是一个很复杂的问题，很难用三言两语说清楚。我在这里从SQL
Server索引优化查询的角度简单谈谈(如果对这方面感兴趣的话，可以读一读微软出版的《Microsoft SQL Server
2000数据库编程》第3单元的数据结构引论以及第6、13、14单元)。
一、索引块与数据块的区别
大家都知道，索引可以提高检索效率，因为它的二叉树结构以及占用空间小，所以访问速度块。让我们来算一道数学题：如果表中的一条记录在磁盘上占用
1000字节的话，我们对其中10字节的一个字段建立索引，那么该记录对应的索引块的大小只有10字节。我们知道，SQL
Server的最小空间分配单元是“页（Page）”，一个页在磁盘上占用8K空间，那么这一个页可以存储上述记录8条，但可以存储索引800条。现在我
们要从一个有8000条记录的表中检索符合某个条件的记录，如果没有索引的话，我们可能需要遍历8000条×1000字节/8K字节=1000个页面才能
够找到结果。如果在检索字段上有上述索引的话，那么我们可以在8000条×10字节/8K字节=10个页面中就检索到满足条件的索引块，然后根据索引块上
的指针逐一找到结果数据块，这样IO访问量要少的多。
二、索引优化技术
是不是有索引就一定检索的快呢？答案是否。有些时候用索引还不如不用索引快。比如说我们要检索上述表中的所有记录，如果不用索引，需要访问8000
条×1000字节/8K字节=1000个页面，如果使用索引的话，首先检索索引，访问8000条×10字节/8K字节=10个页面得到索引检索结果，再根
据索引检索结果去对应数据页面，由于是检索所有数据，所以需要再访问8000条×1000字节/8K字节=1000个页面将全部数据读取出来，一共访问了
1010个页面，这显然不如不用索引快。
SQL Server内部有一套完整的数据检索优化技术，在上述情况下，SQL Server的查询计划（Search
Plan）会自动使用表扫描的方式检索数据而不会使用任何索引。那么SQL Server是怎么知道什么时候用索引，什么时候不用索引的呢？SQL
Server除了日常维护数据信息外，还维护着数据统计信息，下图是数据库属性页面的一个截图：
从图中我们可以看到，SQL Server自动维护统计信息，这些统计信息包括数据密度信息以及数据分布信息，这些信息帮助SQL
Server决定如何制定查询计划以及查询是是否使用索引以及使用什么样的索引（这里就不再解释它们到底如何帮助SQL
Server建立查询计划的了）。我们还是来做个实验。建立一张表：tabTest(ID,
unqValue，intValue)，其中ID是整形自动编号主索引，unqValue是uniqueidentifier类型，在上面建立普通索
引，intValue 是整形，不建立索引。之所以挂上一个没有索引的intValue字段，就是防止SQL
Server使用索引覆盖查询优化技术，这样实验就起不到作用了。向表中录入10000条随机记录，代码如下：
CREATE TABLE [dbo].[tabTest] ( [ID] [int] IDENTITY (1, 1) NOT NULL , [unqValue] [uniqueidentifier] NOT NULL , [intValue] [int] NOT NULL ) ON [PRIMARY] GO ALTER TABLE [dbo].[tabTest] WITH NOCHECK ADD CONSTRAINT [PK_tabTest] PRIMARY KEY CLUSTERED ( [ID] ) ON [PRIMARY] GO ALTER TABLE [dbo].[tabTest] ADD CONSTRAINT [DF_tabTest_unqValue] DEFAULT (newid()) FOR [unqValue] GO CREATE INDEX [IX_tabTest_unqValue] ON [dbo].[tabTest]([unqValue]) ON [PRIMARY] GO declare @i int declare @v int set @i=0 while @i<10000 begin set @v=rand()*1000 insert into tabTest ([intValue]) values (@v) set @i=@i+1 end 然后我们执行两个查询并查看执行计划，如图：（在查询分析器的查询菜单中可以打开查询计划，同时图上第一个查询的GUID是我从数据库中找的，大家做实验的时候可以根据自己数据库中的值来定）：
从
图中可以看出，在第一个查询中，SQL
Server使用了IX_tabTest_unqValue索引，根据箭头方向，计算机先在索引范围内找，找到后，使用Bookmark
Lookup将索引节点映射到数据节点上，最后给出SELECT结果。在第二个查询中，系统直接遍历表给出结果，不过它使用了聚簇索引，为什么呢？不要忘
了，聚簇索引的页节点就是数据节点！这样使用聚簇索引会更快一些（不受数据删除、更新留下的存储空洞的影响，直接遍历数据是要跳过这些空洞的）。
下面，我们在SQL Server中将ID字段的聚簇索引更改为非聚簇索引，然后再执行select * from tabTest，这回我们看到的执行计划变成了：
SQL Server没有使用任何索引，而是直接执行了Table Scan，因为只有这样，检索效率才是最高的。
三、聚簇索引与非聚簇索引的本质区别
现在可以讨论聚簇索引与非聚簇索引的本质区别了。正如本文最前面的两个图所示，聚簇索引的叶节点就是数据节点，而非聚簇索引的页节点仍然是索引检点，并保留一个链接指向对应数据块。
还是通过一道数学题来看看它们的区别吧：假设有一8000条记录的表，表中每条记录在磁盘上占用1000字节，如果在一个10字节长的字段上建立非
聚簇索引主键，需要二叉树节点16000个（这16000个节点中有8000个叶节点，每个页节点都指向一个数据记录），这样数据将占用8000条
×1000字节/8K字节=1000个页面；索引将占用16000个节点×10字节/8K字节=20个页面，共计1020个页面。
同样一张表，如果我们在对应字段上建立聚簇索引主键，由于聚簇索引的页节点就是数据节点，所以索引节点仅有8000个，占用10个页面，数据仍然占有1000个页面。
下面我们看看在执行插入操作时，非聚簇索引的主键为什么比聚簇索引主键要快。主键约束要求主键不能出现重复，那么SQL
Server是怎么知道不出现重复的呢？唯一的方法就是检索。对于非聚簇索引，只需要检索20个页面中的16000个节点就知道是否有重复，因为所有主键
键值在这16000个索引节点中都包含了。但对于聚簇索引，索引节点仅仅包含了8000个中间节点，至于会不会出现重复必须检索另外1000个页数据节点
才知道，那么相当于检索10+1000=1010个页面才知道是否有重复。所以聚簇索引主键的插入速度要比非聚簇索引主键的插入速度慢很多。
让我们再来看看数据检索的效率，如果对上述两表进行检索，在使用索引的情况下（有些时候SQL
Server执行计划会选择不使用索引，不过我们这里姑且假设一定使用索引），对于聚簇索引检索，我们可能会访问10个索引页面外加1000个数据页面得
到结果（实际情况要比这个好），而对于非聚簇索引，系统会从20个页面中找到符合条件的节点，再映射到1000个数据页面上（这也是最糟糕的情况），比较
一下，一个访问了1010个页面而另一个访问了1020个页面，可见检索效率差异并不是很大。所以不管非聚簇索引也好还是聚簇索引也好，都适合排序，聚簇
索引仅仅比非聚簇索引快一点。
结语
好了，写了半天，手都累了。关于聚簇索引与非聚簇索引效率问题的实验就不做了，感兴趣的话可以自己使用查询分析器对查询计划进行分析。SQL
Server是一个很复杂的系统，尤其是索引以及查询优化技术，Oracle就更复杂了。了解索引以及查询背后的事情不是什么坏事，它可以帮助我们更为深
刻的了解我们的系统。
SQL Server基础知识之:设计和实现视图
设计和实现视图可谓是数据库物理设计中的一个非常重要的步骤。从一般意义上说，设计和实现视图应该遵循下面的一些建议和原则。
以下内容摘在文档，我对某些重点进行了补充说明（红色部分）
- 只能在当前数据库中创建视图。 但是，如果使用分布式查询定义视图，则新视图所引用的表和视图可以存在于其他数据库甚至其他服务器中。
- 分布式视图是可行的，但随着SQL Server本身能力的提高，例如SQL Server 2005开始支持表分区等技术之后，分布式视图应该尽量少用。
- 所谓分布式视图的一个最大的问题就是将表物理上分开在多个数据库甚至服务器中，这增加了维护和查询的难度
- 视图名称必须遵循标识符的规则，且对每个架构都必须唯一。 此外，该名称不得与该架构包含的任何表的名称相同。
- 一个可以借鉴的做法是：在视图名称之前添加一个前缀 vw
- 您可以对其他视图创建视图。Microsoft SQL Server 允许嵌套视图。但嵌套不得超过 32 层。 根据视图的复杂性及可用内存，视图嵌套的实际限制可能低于该值。不能将规则或 DEFAULT 定义与视图相关联。
- 一般不建议超过2层
- 不能将 AFTER 触发器与视图相关联，只有 INSTEAD OF 触发器可以与之相关联。
- 除非万不得已，一般不建议使用触发器
- 定义视图的查询不能包含 COMPUTE 子句、COMPUTE BY 子句或 INTO 关键字。
- 很多朋友不知道：COMPUTER和COMPUTER BY语句仅仅用于一些特殊场合，用于生成总计行。大致有如下的效果
该特性不能用于视图，但可以直接用于查询
- 定义视图的查询不能包含 ORDER BY 子句，除非在 SELECT 语句的选择列表中还有一个 TOP 子句。定义视图的查询不能包含指定查询提示的 OPTION 子句。
- 这个很有意思，如果要访问所有的呢，还必须是写TOP 100 PERCENT
- 定义视图的查询不能包含 TABLESAMPLE 子句。不能为视图定义全文索引定义。
- 关于TABLESAMPLE语句，大家可能也比较陌生，这是一个用于对数据进行抽样的。它和TOP语句不同，TOP语句是有固定大小的，而TABLESAMPLE返回的数据，可能多，可能少，甚至可能没有
- 我之前有一篇文章讲述这个语法 http://www.cnblogs.com/chenxizhang/archive/2009/05/19/1460040.html
- 不能创建临时视图，也不能对临时表创建视图。
- 在SQL Server 2005中，可以通过CTE（Common Table Expression)来实现该功能
- 之前的版本，大致的做法是使用临时表，表变量，函数等等
- 不能删除参与到使用 SCHEMABINDING 子句创建的视图中的视图、表或函数，除非该视图已被删除或更改而不再具有架构绑定。 另外，如果对参与具有架构绑定的视图的表执行 ALTER TABLE 语句，而这些语句又会影响该视图的定义，则这些语句将会失败。尽管查询引用一个已配置全文索引的表时，视图定义可以包含全文查询，仍然不能对视图执行全文查询。
-
如果未使用 SCHEMABINDING 子句创建视图，则对视图下影响视图定义的对象进行更改时，应运行 sp_refreshview。 否则，当查询视图时，可能会生成意外结果。
- 如果你修改了一个表，那么如何刷新所有与该表有关的视图呢
- 强烈建议对某些非常重要的视图，添加SCHEMABINDING 子句。
-
如果未使用 SCHEMABINDING 子句创建视图，则对视图下影响视图定义的对象进行更改时，应运行 sp_refreshview。 否则，当查询视图时，可能会生成意外结果。
- 下列情况下必须指定视图中每列的名称：
- 视图中的任何列都是从算术表达式、内置函数或常量派生而来。
- 视图中有两列或多列原应具有相同名称（通常由于视图定义包含联接，因此来自两个或多个不同表的列具有相同的名称）。
- 希望为视图中的列指定一个与其源列不同的名称。 （也可以在视图中重命名列。） 无论重命名与否，视图列都会继承其源列的数据类型。
若要创建视图，您必须获取由数据库所有者授予的此操作执行权限，如果使用 SCHEMABINDING 子句创建视图，则必须对视图定义中引用的任何表或视图具有相应的权限。
默认情况下，由于行通过视图进行添加或更新，当其不再符合定义视图的查询的条件时，它们即从视图范围中消失。
例如，创建一个定义视图的查询，该视图从表中检索员工的薪水低于 $30,000 的所有行。如果员工的薪水涨到
$32,000，因其薪水不符合视图所设条件，查询时视图不再显示该特定员工。 但是，WITH CHECK OPTION
子句强制所有数据修改语句均根据视图执行，以符合定义视图的 SELECT 语句中所设条件。 如果使用该子句，则对行的修改不能导致行从视图中消失。
任何可能导致行消失的修改都会被取消，并显示错误。