索引

全表扫描：对数据进行检索效率最差的是全表扫描，就是一条一条的找。
聚集索引
索引的顺序与磁盘存储的顺序对应
所以只能有一个聚集索引，否则磁盘存储的顺序就无法确定了


非聚集索引
索引的顺序与磁盘的存储顺序不对应
逻辑顺序与物理顺序不一致


索引意味着排序，排序后则可更高效的查询，但是因为索引也是占据空间的，
而且添加、更新、删除数据的时候也需要同步更新索引，
降低了插入和更新的效率



依赖聚集索引不然就依赖磁盘存储的顺序


填充引子 便于后期数据的插入，而不会改动过多的数据
每页预留8kb，其实数据并存的数据并没有8kb，但便于后期的数据的插入
逻辑读取：从缓存中读取数据。
物理读取：从磁盘中读取数据
预读取：一种性能优化机制，在执行查询时先预测执行“查询计划”所需的数据
和索引页，然后在查询实际使用这些页之前将它们读入缓冲高速缓存。

 

-----------索引演示-------------
--1.打开统计信息：查询→查询选项→高级→SET STATISTICS TIME、SET STATISTICS IO
--2.打开“实际的执行计划”或“估计的执行计划”。
select c3,c4 from TestIndex1002 where c4>800 and c4<1000 order by c4 asc

--建立索引 (因为查询的时候是在c3,c4上建查询，而且查询中对c4排序，而在c4上建立索引就有了排序了)
create clustered index  IXc4 On TestIndex1002(c4)--建立索引之后再执行以上查询语句，就快速多了

--当遇到排序、区间查询的时候，聚集索引可以大大提高性能。
--（如果为一个表建索引，建议先建一个聚集索引，然后再建其他索引。）

--将where条件变为c3='backuplsnparamorhinttext'，再测试select c3,c4 from TestIndex1002 where c3='backuplsnparamorhinttext'，
--虽然有一个聚集索引但是这个查询的where条件并没有充分利用该索引的优点，索引性能提升并不大。
select c3,c4 from TestIndex1002 where c3='backuplsnparamorhinttext'

create nonclustered index IXc3 on TestIndex1002(c3)--这时候查询的效率就大大提高了
--模糊查询，还是会对表全表扫描，
select c3,c4 from TestIndex1002 where c3='%backupls%'
--优化查询
select c3,c4 from TestIndex1002 where c3='backupls%'

------------
--删除索引
drop index  TestIndex1002. IXc4

--下面为 工具——数据库引擎顾问生成的代码  （将sql代码放进数据库中）
CREATE NONCLUSTERED INDEX [_dta_index_TestIndex1002_11_1781581385__K4_3] ON [dbo].[TestIndex1002] 
(
    [c4] ASC
)
INCLUDE ( [c3]) WITH (SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [PRIMARY]