共计 3229 个字符，预计需要花费 9 分钟才能阅读完成。
在 SqlServer 2016 中，当咱们要给一个长度超过 1700 的列创立索引时，数据库会通知咱们为这个列建索引会超过限度，而 include 的列是不在这个限度外面的。
create table t1(hid int,hname varchar(4000),hname1 varchar(4000))
create index ind_hname on t1(hname) – 正告 Warning! The maximum key length
for a nonclustered index is 1700 bytes. The index ‘ind_hname’ has maximum length of
4000 bytes. For some combination of large values, the insert/update operation will fail.
create index ind_hname on t1(hid) include(hname) – 不报错，失常创立，索引键列是 hid，蕴含列是 hname
官网文档的说法：通过蕴含非键列，能够创立笼罩更多查问的非汇集索引。这是因为非键列具备下列长处：
1、它们能够是不容许作为索引键列的数据类型。
2、在计算索引键列数或索引键大小时，数据库引擎不思考它们。
当查问中的所有列都作为键列或非键列蕴含在索引中时，带有蕴含性非键列的索引能够显著进步查问性能。这样能够实现性能晋升，因为查问优化器能够在索引中找到所有列值；不拜访表或汇集索引数据，从而缩小磁盘 I/O 操作。
以上 2 点的集体了解：
1、它们能够是不容许作为索引键列的数据类型。比方 varchar(2000)超过 1700 不能做索引键列，然而 varchar(2000)能够作为蕴含列
2、index key size 索引键大小是指索引键蕴含的所有字段的长度总和的限度，比方我有一个表 create table table1 (col1 varchar(500), col2 varchar(500),col3 varchar(500), col4 varchar(500)); 因为 indexed key size 的限度是 1700，所以 create index ind_t1 on table1(col1, col2,col3) 没有问题, 因为 col1+col2+col3=1500<1700，然而 create index ind_t2 on table1(col1, col2,col3,col4)有问题，因为 col1+col2+col3+col4=2000>1700, 然而咱们能够这样 create index ind_t3 on table1(col1, col2,col3) include (col4)，即把 col4 放入蕴含列，它就不占索引键 ind_t3 的大小
联合以上 2 点的了解，得出结论
1、include 蕴含列只能是针对非游戏汇集索引
2、Index space<>indexed key size+include columns size, Index space 是整个 index 段的尺寸包含 include 列，Index space 就是整个索引占用的磁盘空间，它包含索引键和非索引键，而不是说非索引键(蕴含列) 就不占索引段的磁盘空间
3、当查问中的所有列就蕴含于索引的键值中，那么就不会产生 Lookup 回表的操作了，因为找到索引项，就曾经找到所需的数据了，没有必要再到数据行去找了，这种状况，叫做索引笼罩
4、索引定义中非键列(蕴含列) 的程序不会影响应用该索引的查问的性能。
5、忽然多进去一个查问，而这个查问字段只是比之前的查问多一个字段的状况下，如果之前的查问曾经有了索引，则能够把之前索引删除，新建一个索引，再把新增的查问字段和之前索引中 include 字段合并起来一并放入 include
6、当查问中的所有列都呈现在索引 (键列或蕴含列) 中时，这种蕴含列的索引能力带来成果，也就是说它惟一的益处就是间接查问索引就能够返回值，不必回表，应用的范畴太窄了。一旦要通过索引再回表返回数据，那蕴含列太得失相当，因为蕴含列也占用理论的存储空间，这样导致这个索引的 index space 太大了，老本太高了，特地是超大表，索引如果蕴含太多蕴含列的话，占用存储切实太可怕了。所以 include 蕴含列是典型的空间换工夫的打法，须要均衡场景应用，而不是说它肯定很好
以下 7、8 两点论断，额定夹带的私活，帮忙了解索引扫描的原理
7、100GB 的表，10 个字段，每个字段均匀 10GB，每个字段建设一个索引，均匀每个索引 10GB，扫描某个索引时，不是间接扫描整个索引这 10GB，而是扫描索引树根节点 + 索引树干节点 + 索引叶子节点，这样下来找到对应的索引键值，可能只须要扫描不到 10MB 的索引，如果要回表，那再加上回表的老本
8、大表创立索引，加上 online=on 不会影响业务，然而会产生微小的事务日志，所以个别留到业务低峰比方周末操作
论断 2 的例子：
20210526 公司产生的遇到的景象，csdb5 的磁盘一下子被应用了 200GB
如下语句，ATickMinutesArchive 表大小 254GB 总计 10 个字段，原来的索引 180GB，如下索引一创立，发现索引达到了 400GB，也就是如下新建索引有 200GB，这个索引大小刚好和表大小统一，阐明 include 的 8 个字段和索引键的 2 个字段同时计算了到了索引大小中
CREATE NONCLUSTERED INDEX NIX_ATickMinutesArchive_001
ON [dbo].[ATickMinutesArchive] ([Symbol],[DateUpdate])
INCLUDE ([Last],[High],[Low],[TotalVol],[TimeUpdate],[Ticks],[OpenPrice],[OpenVolume])
WITH (ONLINE= ON)
论断 3 的例子 1：
例如，taable1 表上有 col1 列 (主键)，col2 列，col3 列，col4 列，col5 列 …
当初要求作以下查问 select col2,col3 from taable1 where col2=@col2
一般来说，在 col2 列上加 www.cungun.com 非汇集索引，就能够减速此查问。其查问步骤：检索 col2 列上的非汇集索引，获取对应主键 col1，再由主键检索汇集索引，从汇集索引的叶级索引页上获取相干的记录。然而，如果在 col2 列上加非汇集索引时指定 include col3 列，这样 col3 列值便会存储在非汇集索引的叶级索引页上。其查问步骤：检索 col2 列上的非汇集索引，间接从非汇集索引的叶级索引页上获取相干记录。
论断 3 的例子 2：
如遇到如下查问，则最初一个 index_5 都能够让上面这些所有查问语句只拜访索引就返回数据，也就是说当查问中的所有列都作为键列或非键列蕴含在索引中时，间接查问索引就能够返回后果
select col1,col2 from table1 where col1=XX
select col1,col2,col3 from table1 where col1=XX
select col1,col2,col3,col4 from table1 where col1=XX
select col1,col2,col3,col4,col5 from table1 where col1=XX
select col1,col2,col3,col4,col5,col6 from table1 where col1=XX
CREATE INDEX [index_5] ON [dbo].[table1] ([col1]) INCLUDE ([col2], [col3],
[col4], [col5], [col6]) WITH (DATA_COMPRESSION = PAGE, ONLINE = ON)
论断 4 的例子：
索引定义中非键列的程序不会影响应用该索引的查问的性能，比方 index_5 和 index_6 成果一样，include 前面的 col2 和 col5 程序能够随便，能够 col2 在前，也能够 col5 在前
