首页 > 代码库 > INDEX--从数据存放的角度看索引
INDEX--从数据存放的角度看索引
测试表结构：
CREATE TABLE TB1( ID INT IDENTITY(1,1), C1 INT, C2 INT)
1. 聚集索引(Clustered index)
聚集索引可以理解为一个包含表中除索引键外多有剩余列的包含索引，为保证在DELETE/UPDATE操作的正确性，如果聚集索引未声明为唯一(UNIQUE),则系统会聚集索引键增加一个NULLABLE的INT类型标识列(UNIQUIFIER)以保证记录唯一性。
唯一聚集索引：
CREATE UNIQUE CLUSTERED INDEX IDX_IDON TB1( ID)
非唯一聚集索引：
CREATE CLUSTERED INDEX IDX_IDON TB1( ID)
2. 非唯一非聚集索引
为从非聚集索引定位到数据，对于堆表，非聚集索引会存放索引键+数据的RID(FILE_ID+PAGE_ID+SLOT_ID),对于聚集表，非聚集索引会存放索引键+聚集索引键。
非聚集索引：
CREATE INDEX IDX_C1ON TB1( C1)
堆表上非聚集索引：
唯一聚集索引表上非聚集索引：
非唯一聚集索引表非聚集索引：
--==============================
后续的测试默认使用唯一聚集索引
--==============================
3. 唯一非聚集索引
唯一非聚集索引与非唯一非聚集索引的区别主要在非叶子节点上，唯一非聚集索引的非叶子节点上不会包含RID的数据。
唯一非聚集索引：
CREATE UNIQUE INDEX IDX_C1_UNION TB1( C1)
4. 包含索引
包含索引在SQL SERVER 2008版本中引入，包含列的数据只存在在叶子节点上。包含列不影响索引行的位置(不会被排序)，且包含列不会影响索引键的大小(SQL SERVER 限制索引键不得超过900字节)
CREATE INDEX IDX_C1_INC_C2ON TB1( C1)INCLUDE( C2)
5. 过滤索引
当过滤列不作为索引键或包含列时，系统无需在索引中存放过滤列的数据，因此过滤列不会出现在索引的叶子节点和非叶子节点上。
CREATE INDEX IDX_C1_WH_C2ON TB1( C1)WHERE C2>1
--=============================================================
总结&建议：
1. 对于聚集表，由于索引非聚集索引都会包含聚集键，因此建议优先考虑静态+唯一+递增+长度较小的索引键作为索引键
a. 静态：当聚集键被更新时，除了将表数据移动到相应的位置上，依次更新所有的非聚集索引，会消耗大量资源，并导致页拆分和索引碎片
b. 唯一: 非唯一聚集索引增加2至6个字节的消耗，导致聚集索引和非聚集索引消耗更多页面
c. 递增：对于非递增的聚集索引键来说，插入操作会引发页拆分和索引碎片
d. 长度较小：长度较大的聚集索引键同样会导致聚集索引和非聚集索引消耗更多页面，尤其是导致索引层数增加，增加INDEX SEEK的开销。
2. 索引列的可选择性和索引列顺：高选择性不代表该列就适合放在索引前部，还应该考虑针对该列是范围查询还是等值查询，如订单表的创建时间列CreatedTime主要用作范围查询，而订单表的产品编号ProductID主要用等值查询，那么对于
WHERE ProductID=@P1 AND CreatedTime>@P2AND CreatedTime<@p3
这样的查询，索引 INDEX(ProductID,CreatedTime)就会比INDEX(CreatedTime,ProductID) 更高效(消耗更少的CPU和IO资源)。
3. 索引列顺序与统计：索引列先后顺序不同，其对于的统计信息的密度(density)和直方图(histogram)也不相同，会间接影响到生成的执行计划。
4. 对于选择性较低且位于索引列后端的列来说，可以考虑将其放入到包含索引列中。
5. 虽然过滤索引在统计信息更新方面存在一定的问题，过滤索引依然是解决部分疑难杂症的必杀技(如SELECT TOP(10) * FROM orders WHERE ProductID>10000 ORDER BY OrderID DESC)
6. 在对递增的列建立索引时，应考虑统计过期导致执行计划低效的问题，如对订单表上创建日期列建立索引。
--==========================================================
写得不好，靠妹子加分啦。。
INDEX--从数据存放的角度看索引