为节省存储空间和提高搜索效率,搜索引擎在索引页面或处理搜索请求时会自动忽略某些字或词,这些字或词即被称为Stop Words(停用词).

通常意义上,大致为如下两类:

1,这些词应用十分广泛,在Internet上随处可见,比如“Web”一词几乎在每个网站上均会出现,对这样的词搜索引擎无法保证能够给出真正相关的搜索结果,难以帮助缩小搜索范围,同时还会降低搜索的效率;

2,这类就更多了,包括了语气助词,副词,介词,连接词等,通常自身并无明确的意义,只有将其放入一个完整的句子中才有一定作用,如常见的“的“,”在“之类.举个例子来说,象“IT技术点评“,虽然其中的“IT”从我们的本意上是指“Information Technology”,事实上这种缩写也能够为大多数人接受,但对搜索引擎来说,此“IT”不过是“it”,即“它“的意思,这在英文中是一个极其常见同时意思又相当含混的词,在大多数情况下将被忽略.我们在IT技术点评中保留“IT”更多地面向“人“而非搜索引擎,以求用户能明了IT技术点评网站涉及的内容限于信息技术,虽然从SEO的角度这未必是最佳的处理方式.

了解Stop Words,在网页内容中适当地减少Stop Words出现的频率,可以有效地帮助我们提高关键词密度,而在网页Title中避免出现Stop Words往往能够让我们优化的关键词更突出.

Google stop words list:比如 I,a,about,an,are,as,at,be,by,com,de,of,on,or,that,what,when,where,who…

中文停止词:”在“,”里面“,”也“,”的“,”它“,”为“这些词都是停止词.这些词因为使用频率过高,几乎每个网页上都存在,所以搜索引擎开发人员都将这一类词语全部忽略掉.

在 SQL Server 2005 中,可以通过将非键列添加到非聚集索引的叶级别来扩展非聚集索引的功能.通过包含非键列,可以创建覆盖更多查询的非聚集索引.这是因为非键列具有下列优点:

1.它们可以是不允许作为索引键列的数据类型. 

2.在计算索引键列数或索引键大小时,数据库引擎不考虑它们.

3.当查询中的所有列都作为键列或非键列包含在索引中时,带有包含性非键列的索引可以显著提高查询性能.这样可以实现性能提升,因为查询优化器可以在索引中找到所有列值;不访问表或聚集索引数据,从而减少磁盘 I/O 操作.

注意:当索引包含查询引用的所有列时,它通常称为”覆盖查询”.  

4.键列存储在索引的所有级别中,而非键列仅存储在叶级别中.

5.使用包含性列以避免大小限制.

6.可以将非键列包含在非聚集索引中,以避免超过当前索引大小的限制(最大键列数为 16,最大索引键大小为 900 字节).数据库引擎 计算索引键列数或索引键大小时,不考虑非键列. 

 

例如,假设要为 AdventureWorks 示例数据库的 Document 表中的以下列建立索引:

  Title nvarchar(50) 

  Revision nchar(5)

  FileName nvarchar(400) 

因为 nvarchar 数据类型要求每个字符 2 个字节,所以包含这三列的索引将超过 900 字节的大小限制,多了 10 个字节 (455 * 2).使用 CREATE INDEX 语句的 INCLUDE 子句,可以将索引键定义为 (Title, Revision),将FileName 定义为非键列.这样,索引键大小将为 110 个字节 (55 * 2),并且索引仍将包含所需的所有列.下面的语句就创建了这样的索引.

USE AdventureWorks;

GO

CREATE INDEX IX_Document_Title  

ON Production.Document (Title, Revision)  

INCLUDE (FileName);  

 

带有包含性列的索引准则

1.设计带有包含性列的非聚集索引时,请考虑下列准则: 

2.在 CREATE INDEX 语句的 INCLUDE 子句中定义非键列.

3.只能对表或索引视图的非聚集索引定义非键列.

4.除 text,ntext 和 image 之外,允许所有数据类型.

5.精确或不精确的确定性计算列都可以是包含性列.

6.与键列一样,只要允许将计算列数据类型作为非键索引列,从 image,ntext 和 text 数据类型派生的计算列就可以作为非键(包含性)列. 

7.不能同时在 INCLUDE 列表和键列列表中指定列名.

8.INCLUDE 列表中的列名不能重复.

 

列大小准则

1.必须至少定义一个键列.最大非键列数为 1023 列.也就是最大的表列数减 1.

2.索引键列(不包括非键)必须遵守现有索引大小的限制(最大键列数为 16,总索引键大小为 900 字节).

3.所有非键列的总大小只受 INCLUDE 子句中所指定列的大小限制;例如,varchar(max) 列限制为 2 GB.

 

列修改准则,修改已定义为包含性列的表列时,要受下列限制:

1.除非先删除索引,否则无法从表中删除非键列.

2.除进行下列更改外,不能对非键列进行其他更改:将列的为空性从 NOT NULL 改为 NULL.

3.增加 varchar,nvarchar 或 varbinary 列的长度. 

注意:这些列修改限制也适用于索引键列. 

 

设计建议

重新设计索引键大小较大的非聚集索引,以便只有用于搜索和查找的列为键列.将覆盖查询的所有其他列设置为包含性非键列.这样,将具有覆盖查询所需的所有列,但索引键本身较小,而且效率高.

 

例如,假设要设计覆盖下列查询的索引.

USE AdventureWorks;

GO

SELECT AddressLine1, AddressLine2, City, StateProvinceID, PostalCode

FROM Person.Address

WHERE PostalCode BETWEEN N’98000′ and N’99999′;

若要覆盖查询,必须在索引中定义每列.尽管可以将所有列定义为键列,但键大小为 334 字节.因为实际上用作搜索条件的唯一列是 PostalCode 列(长度为 30 字节),所以更好的索引设计应该将 PostalCode 定义为键列并包含作为非键列的所有其他列. 

下面的语句创建了一个覆盖查询的带有包含性列的索引.

USE AdventureWorks;

GO

CREATE INDEX IX_Address_PostalCode  

ON Person.Address (PostalCode)  

INCLUDE (AddressLine1, AddressLine2, City, StateProvinceID);  

 

性能注意事项

1.避免添加不必要的列.添加过多的索引列(键列或非键列)会对性能产生下列影响:一页上能容纳的索引行将更少.这样会使 I/O 增加并降低缓存效率.

2.需要更多的磁盘空间来存储索引.特别是,将 varchar(max),nvarchar(max),varbinary(max) 或 xml 数据类型添加为非键索引列会显著增加磁盘空间要求.这是因为列值被复制到了索引叶级别.因此,它们既驻留在索引中,也驻留在基表中.

3.索引维护可能会增加对基础表或索引视图执行修改,插入,更新或删除操作所需的时间.

 

您应该确定修改数据时在查询性能上的提升是否超过了对性能的影响,以及是否需要额外的磁盘空间要求.