MSSQL教程之索引视图

因此我们看到，这些信息足够让我们对单个操作实现“逆操作”。在后面我们已提到过有关视图的下述概念：因为视图前往的了局集与具有行列布局的表有着不异的表格情势，而且我们能够在SQL语句中像援用表那样援用视图，以是我们常把视图称为虚表。尺度视图的了局集其实不以表的情势存储在数据库中，而是在实行援用了视图的查询时，SQLServer2000才把相干的基础表中的数据兼并成视图的逻辑布局。
下面的结论常让我们发生如许的焦急：因为是在实行了援用了视图的查询时，SQLServer2000才把相干的基础表中的数据兼并成视图的逻辑布局，那末当查询所援用的视图包括大批的数据行或触及到对大批数据行举行算计运算或毗连操纵，无庸置疑，静态地创立视图了局集将给体系带来极重的包袱，特别是常常援用这类年夜容量视图。
办理这一使人头痛成绩的办法就是为视图创立聚簇索引，只要如许才会明显地进步体系的功能。当在视图上创立了聚簇索引后，视图的了局集与有聚簇索引的表的数据集一样是存储在数据中的。
别的，在视图上创立索引还会带来如许的优点；优化器能够在那些在FROM从句中不间接定名视图的查询中利用视图索引，并且对已存在的视图而言，因为不用从头编写查询代码，从而进步了查询从索引视图中检索数据的效力。
假如在视图上创立索引，那末视图中的数据会被当即存储在数据库中，对索引视图举行修正，那末这些修正会当即反应到基本表中。同理，对基本表所举行的数据修正也会反应到索引视图那边。索引的唯一性年夜年夜进步了SQLServer查找那些被修正的数据行。
保护索引视图比保护基本表的索引更加庞大。以是，假如以为值得以因数据修正而增添体系包袱为价值来进步数据检索的速率，那末应当在视图上创立索引。在为视图创立索引前，视图自己必需满意以下前提：

• 在实行CREATEVIEW命令时，必需将ANSI_NULLS和QUOTED_IDENTIFIER选项设置为ON形态；
  
• 在利用CREATETABLE命令创立索引所援用的基本表时，ANSI_NULLS选项应设置为ON；
  
• 该视图所援用的工具仅包含基本表而不包含别的的视图；
  
• 视图所援用的基本表必需与视图同属于统一数据库且有不异的一切者；
  
• 在创立视图时必需利用SCHEMABINDING选项；
  
• 假如视图援用了用户自界说函数，那末在创立这些用户自界说函数时也必需利用SCHEMABINDING选项；
  
• 视图必需以owner.objectname的情势来使所援用的表或用户自界说函数；
  
• 视图所援用的函数必需是断定性的；
  
• 别的值得注重的是，在创立视图的SELECT语句中不该该包括上面的Transact-SQL语法；
  
• SELECT语句中不克不及利用*或tablename.*来界说列，必需间接给出列名，不然不成以；
  
• 暗示行汇合的函数；
  
• UNION、DISTINCT、TOP、ORDERBY、COMPUTE、COMPUTEBY、COUNT（*）等；
  
• AVG、MAX、MIN、STDEV、STDEVP、VAR和VARP等算计运算函数。
  一般而言，能够在视图上创立多个索引，可是应当记着，在视图上所创立的第一个索引必需是聚簇索引，然后才能够创立别的的非聚簇索引。
  在第八章我们已具体先容了CREATEINDEX命令可是假如筹办为视图创立索引那末在实行该命令之前您必需确保以下前提不然创立将会失利。
  
• CREATEINDEX命令的实行者必需是视图的一切者；
  
• 在实行创立索引命令时代，ANSI_NULLS、ANSI_PADDING、ANSI_WARNINGS、ARITHABORT、CONCAT_NULL_YIELDS_NULL、QUOTED_IDENTIFIERS诸选项应被设置成ON形态；
  
• NUMERIC_ROUNDABORT选项被设置为OFF形态；
  
• 视图不克不及包含text、ntext、image范例的数据列；
  
• 假如视图的SELECT语句中包括ORDERBY选项，则聚簇索引的关头值只能是ORDERBY从句中所界说的数据列。
  

在视图上创立了索引以后，假如盘算修正视图数据，则应当包管修正时的选项设置与创立索引时的选项设置一样，不然SQLServer将发生毛病信息，并回滚所做的INSERT、UPDATE和DELETE操纵。

我们只需要把binlog文件反向执行，每个操作都执行逆操作即可。当然也不是所有的event都反转。Table_mapevent必须还是在Rows_log_event每个操作之前。

从底层原理到表层引用，书籍多的很。个人认为没有什么那本书好？这样的说法。主要看和个人的学习方法是否适合。

但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。

如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录.

Mirror可以算是SQLServer的Dataguard了。但是能不能被大伙用起来就不知道了。

始终遗憾SQLServer的登陆无法分配CPU/内存占用等指标数。如果你的SQLServer给别人分配了一个只可以读几个表的权限，而这个家伙疯狂的死循环进行连接查询，会给你的系统带来很大的负担。

varchar(max)\\\\nvarchar(max)类型的引入大大的提高了编程的效率，可以使用字符串函数对CLOB类型进行操作，这是一个亮点。

其中最有名的应该是row_number了。这个终于解决了用临时表生成序列号的历史，而且SQLServer2005的row_number比Oracle的更先进。因为它把Orderby集成到了一起，不用像Oracle那样还要用子查询进行封装。