sqlsever 关于索引

索引:

在sqlserver中,存储的单位最小是页,页是不可再分的
B树:初衷是减少对磁盘的扫描次数,如果一个表或者索引没有使用B树(对于没有聚集索引的表是使用 Heap 堆进行存储的),那么查找一个数据,需要在整个表包含的数据库页中进行全盘扫描,这大大增加了IO负担
打包sqlserver使用B树进行存储,只仅仅需要将B树根节点存入内存,经过几次查找后找到存放所需的数据在子页包含的节点的页,这样避免了进行全盘扫描,从而提高了性能

如果表中没有任何索引,则以堆进行存放,

可以通过在其上加上 聚集索引(以B树存放)来展现对IO的减少

例如:

--开启IO数量
SET STATISTICS IO ON
SELECT * FROM student

--给表建立聚集索引
--
CREATE INDEX test_index ON student(id)
SET STATISTICS IO ON
SELECT * FROM student WHERE id = 5

聚集:在sqlserver中:聚集的作用是将一列或是多列的物理顺序改变为和逻辑顺序相一致

聚集索引改变的是其所在表的物理存储顺序,所以每个表只能有一个聚集索引

在sqlserver中:聚集索引的存储是以B树存储,B树的叶子直接存储聚集索引的数据
非聚集索引:并不改变其所在表的物理结构,而是额外生成一个聚集索引的B树结构,但叶子节点是对于其所在表的引用,
这个引用分为两种:如果其所在表没有聚集索引,则引用行号,如果其所在表已经有了聚集索引,则引用聚集索引的页

非聚集索引需要额额外的空间进行存储,按照被索引列进行聚集索引,并在B树的叶子节点包含指向非聚集索引所在表的指针

与聚集索引不同的是:B树的叶子节点存的是指向堆或聚集索引的指针

非聚集索引仅仅包含原表中非聚集索引的列和指向实际物理表的指针。

如果表的物理结构发生改变,比如加上或者删除聚集索引,则所有非聚集索引都需要重建,这个对于性能的损耗是相当大的,所以最好先建立聚集索引,再建立对应的非聚集索引

大多数情况下:聚集索引的速度比非聚集索引都稍微快点,因为聚集索引的B树叶子节点直接存储数据,而非聚集索引还需要额外通过叶子节点的指针找到数据

还有:对于大量连续数据查找,非聚集索引性能十分不好,因为非聚集索引需要在非聚集索引的B树中找到每一行的指针,再去其所在表找数据,性能大打折扣,还不如不加非聚集索引

因此大多数情况下,聚集索引的速度都快于非聚集索引,但聚集索引只有一个,则一定要选择好使用哪个或者哪些列作为聚集索引

索引的使用:
索引的使用不需要显式使用,建立索引后查询分析器会自动找出最短路径使用索引

但是随着数据量的增长,产生了索引碎片,很多存储的数据进行了不适当的夸页,会造成碎片(跨页,碎片,填充因子) 这时候需要重新建立索引以加快性能

可以通过DMV语句查询其索引情况

SELECT index_type_desc,alloc_unit_type_desc,avg_fragmentation_in_percent,fragment_count,avg_fragment_size_in_pages,page_count,record_count,avg_page_space_used_in_percent
FROM sys.dm_db_index_physical_stats(DB_ID(‘Yip_20160322‘),OBJECT_ID(‘student‘),NULL,NULL,‘Sampled‘)

当碎片量超过40%的时候(查看该列:avg_fragmentation_in_percent)往往需要重建索引,这样可以减少IO

可以这样重建索引:
ALTER INDEX idx_student_Id ON Student REBUILD

和更新表的统计信息

UPDATE STATISTICS Student

使用索引后的代价:

1 当表建立索引后,就以B树来存储数据,所以当对其进行更新插入删除时,就需要页在物理上的移动以调整B树,因此,会带来性能下降,
2 对于非聚集索引,当更新表后,非聚集索引也需要更新,相当于多更新了N(N=非聚集索引数量)个表,因此也下降了性能

3 通常可以将非聚集索引全部放在另外一个独立硬盘上,这样可以分散IO,这样可以使查询并行

时间: 2024-08-24 14:22:42

sqlsever 关于索引的相关文章

MS SqlSever一千万条以上记录分页数据库优化经验总结【索引优化 + 代码优化】[转]

对普通开发人员来说经常能接触到上千万条数据优化的机会也不是很多,这里还是要感谢公司提供了这样的一个环境,而且公司让我来做优化工作.当数据库中的记录不超过10万条时,很难分辨出开发人员的水平有多高,当数据库中的记录条数超过1000万条后,还是蛮能考验开发人员的综合技术能力. 当然不是每个公司都能请得起专业的DBA,话又说过来专业的DBA也未必能来我们公司长期工作,这就不只是薪资待遇问题了还会涉及到人家的长期发展规划了,当然我也不是专业的DBA,本着能把问题解决好就是好猫的理念. 我们先看图,数据库

聚集索引与非聚集索引的用法举例与使用注意

聚集索引 用法举例 小明需要查找一个人的姓名,知道他在公司的营销部门的1010办公室的4号座位.这个时候如果需要专门为小明建一个聚集索引表就是,以公司部门表内部门名称排序,再以房间总表序号排序,最后以房间详细表的座位表排序,这样就可以最快的找到他要找的人 聚集索引类似于一个字典,我们知道拼音来寻找字,首先我们知道字音节的首字母,从按a-z排序的字典中找到这个字首字母所在的区域,再从这个区域找到韵母所在的区域,当然韵母在字典中也有顺序,最后就可以找到我们想要的字了 注意事项 限制原则 每个表只能有

ASP.NET + SqlSever 大数据解决方案 PK HADOOP

半个月前看到博客园有人说.NET不行那篇文章,我只想说你们有时间去抱怨不如多写些实在的东西.  1.SQLSERVER优点和缺点? 优点:支持索引.事务.安全性以及容错性高 缺点:数据量达到100万以上就需要开始优化了,一般我们会对 表进行水平拆分,分表.分区和作业同步等,这样做大大提高了逻辑的复杂性,难以维护,只有群集容错,没有多库负载均衡并行计算功能.  2.SQLSERVER真的不能处理大数据? 答案:当然可以的,打个比方:操作单一数据库称为一维操作,如果操作相同结构,分布在多个服务器上的

MySQL 索引优化原则

一.索引优化原则 1.最左前缀匹配原则,联合索引,mysql会从做向右匹配直到遇到范围查询(>.<.between.like)就停止匹配,比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引,d是用不到索引的,如果建立(a,b,d,c)的索引则都可以用到,a,b,d的顺序可以任意调整. 2.=和in可以乱序,比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序,mysql的查询优化器会帮你优

MySQL索引基本应用[转]

原文地址:http://www.php100.com/html/webkaifa/database/Mysql/2010/0409/4279.html 索引是快速搜索的关键.MySQL索引的建立对于MySQL的高效运行是很重要的.下面介绍几种常见的MySQL索引类型. 在数据库表中,对字段建立索引可以大大提高查询速度.假如我们创建了一个 mytable表: CREATE TABLE mytable(   ID INT NOT NULL,    username VARCHAR(16) NOT N

python--15 字典:当索引不好用

字典是python唯一的影射类型 hash >>> brand = ['李宁', '耐克', '阿迪达斯'] >>> slogan = ['一切皆有可能', 'Just do it','Impossible is nothing'] >>> print('李宁的口号是:',slogan[brand.index('李宁')]) 李宁的口号是: 一切皆有可能 字典不是序列类型 ,是映射类型 字符串 列表 元组是序列类型 创建和访问索引   标志性符号--花

MongoDB 学习笔记之 TTL索引,部分索引和文本索引

TTL索引: TTL集合支持mongodb对存储的数据进行失效时间设置,经过指定的时间段后.或在指定的时间点过期,集合自动被mongod清除.这一特性有利于对一些只需要保存一定时间的数据信息进行存储,比如机器产生的事件数据.日志.会话信息等. 先创建一个集合TTLCol: 创建TTL索引,60秒过期. 60秒后查询发现数据被删除了. 部分索引: MongoDB部分索引只为那些在一个集合中,满足指定的筛选条件的文档创建索引.由于部分索引是一个集合文档的一个子集,因此部分索引具有较低的存储需求,并降

CUDA 计算线程索引的一般公式

CUDA thread index: int blockId = blockIdx.z * (gridDim.x*gridDim.y)                    + blockIdx.y * gridDim.x                    + blockIdx.x; int threadId = blockId * (blockDim.x * blockDim.y * blockDim.z)                      + threadIdx.z * (blo

检测和整理索引碎片

索引碎片的检测和整理 存储数据是为了查找数据,存储结构影响数据查找的性能.对无序数据进行查找,最快的查找算法是哈希查找:对有序数据进行查找,最快的查找算法是平衡树查找.在传统的关系型数据库中,聚集索引和非聚集索引都是平衡树(B-Tree)类型的存储结构,用于顺序存储数据,便于实现数据的快速查找.除了提升数据查找的性能之外,索引还能减少硬盘IO和内存消耗.通常情况下,硬盘IO是查找性能的瓶颈,由于索引是数据表的列的子集,这意味着,索引只存储部分列的数据,占用的硬盘空间比全部列少了很多,因此,数据库