sql server 索引阐述系列五 索引参数与碎片

-- 创建聚集索引
create table [dbo].[pub_stocktest] add  constraint [pk_pub_stocktest] primary key clustered
(
[sid] asc
)with (pad_index = off, statistics_norecompute = off, sort_in_tempdb = off, ignore_dup_key = off, online = off, allow_row_locks = on, allow_page_locks = on) on [primary]

-- 创建非聚集索引
 create nonclustered index [ix_model] on [dbo].[pub_stocktest]
(
    [model] asc
)
include (     [name]) with (pad_index = off, statistics_norecompute = off, sort_in_tempdb = off, drop_existing = off, online = off, allow_row_locks = on, allow_page_locks = on, FILLFACTOR = 85) on [primary]

1.1 Filefactor参数

  使用Filefactor可以对索引的每个叶子分页存储保留一些空间。对于聚集索引,叶级别包含了数据,使用Filefactor来控制表的保留空间,通过预留的空间,避免了新的数据按顺序插入时,需腾出空位而进行分页分隔。
  Filefactor设置生效注意,只有在创建索引时才会根据已经存在的数据决定预留的空间大小,如里需要可以alter index重建索引并重置原来指定的Filefactor值。
  在创建索引时,如果不指定Filefactor,就采用默认值0 也就是填充满,可通过sp_configure 来配置全局实例。Filefactor也只就用于叶子级分页上。如果要在中间层控制索引分页,可以通过指定pad_index选项来实现.该选择会通知到索引上所有层次使用相同的Filefactor。Pad_index也只有索引在新建或重建时有用。

1.2 Drop_existing 参数

  删除或重建一个指定的索引作为单个事务来处理。该项在重建聚集索引时格外有用,当删除一个聚集索引时,sqlserver会重建每个非聚集索引以便将书签从聚集索引键改为RID。如果再新建或者重建聚集索引,Sql server会再一次重建全部的非聚集索引,如果再新建或重建的聚集索引键值相同,可以设置Drop_existing=ON。

1.3 IGNORE_DUP_KEY

  是指如果一个update或者insert语句影响多行数据,但有一行键被发现产生重值时,整个语句就会回滚,IGNORE_DUP_KEY=on时产生重复键值时不会引起整个语句的回滚,重复的行会被舍弃其它的行会被插入或更新。

1.4 Statistics_norecompute

  选项决定了是否需要自动更新索引上的统计,每个索引维护着该索引首位字段的数值分布的柱状图,在查询执行计划时,查询优化器利用这些统计信息来判断一个特定索引的有效性。当数据达到一个阀值时,统计值会变。Statistics_norecompute选项允许一个关联的索引在数据修改时不自动更新统计值。该选择覆盖了auto_update_statistics的on值。

1.5 ONLINE   

  值默认OFF, 索引操作期间,基础表和关联的索引是否可用于查询和数据修改操作。
  当值为ON时,能够继续对基础表和索引进行查询或更新,但在短时间内获取sch_m架构修改锁,必须等待此表上的所有阻塞事务完成,在操作期间,此锁会阻止所有其它事务。
  当值为OFF时,可以会获取共享锁,防止更新基础表,但允许读操作

1.6 MAXDOP

  索引操作期间替代max degree of parallelism 实例配置,默认值为0, 根据当前系统工作负荷使用实际数量的处理器。

1.7 包含性列(included columns)
  包含列只在叶级别中出现,不控制索引行的顺序,它作用是使叶级别包含更多信息从而覆盖索引的调优能力,覆盖索引只出现在非聚集索引中,在叶级别就可以找到满足查询的全部信息。

1.8 on [primary]

  在创建索引时 create index 最后一个子句允许用户指定索引被放置在哪里。可以指定特定的文件组或预定义的分区方案。默认存放与表文件组相同一般都是主文件组中。

1.9约束和索引

    当我们创建主键或者唯一性约束时,会创建一个唯一性索引,被创建出来支持约束的索引名称与约束名称相同。
  约束是一个逻辑概念,而索引是一个物理概念,建立索引实际是创建一个占用存储空间并且在数据修改操作中必须得到维护的物理结构。
  创建约束就索引内部结构或优化器的选择来看是没有区别的。

二 索引碎片  

  2.1 SHOWCONTIG 

--   SQLserver 2000使用SHOWCONTIG查看索引碎片 (已过时)
dbcc SHOWCONTIG (tablename,‘indexname‘) 

  例如下面查询一个PUB_StockCollect表下的IX_StockModel索引

  (1)Page Scanned-扫描页数:如果你知道行的近似尺寸和表或索引里的行数,那么你可以估计出索引里的页数。看看扫描页数,如果明显比你估计的页数要高,说明存在内部碎片。

  (2)Extents Scanned-扫描扩展盘区数:用扫描页数除以8,四舍五入到下一个最高值。该值应该和DBCC SHOWCONTIG返回的扫描扩展盘区数一致。如果DBCC SHOWCONTIG返回的数高,说明存在外部碎片。碎片的严重程度依赖于刚才显示的值比估计值高多少。

  (3)Extent Switches-扩展盘区开关数:该数应该等于扫描扩展盘区数减1。高了则说明有外部碎片。

  (4)Avg. Pages per Extent-每个扩展盘区上的平均页数:该数是扫描页数除以扫描扩展盘区数,一般是8。小于8说明有外部碎片。

  (5)Scan Density [Best Count:Actual Count]-扫描密度[最佳值:实际值]:DBCC SHOWCONTIG返回最有用的一个百分比。这是扩展盘区的最佳值和实际值的比率。该百分比应该尽可能靠近100%。低了则说明有外部碎片。

  (6)Logical Scan Fragmentation-逻辑扫描碎片:无序页的百分比。该百分比应该在0%到10%之间,高了则说明有外部碎片。

  (7)Extent Scan Fragmentation-扩展盘区扫描碎片:无序扩展盘区在扫描索引叶级页中所占的百分比。该百分比应该是0%,高了则说明有外部碎片。

  (8)Avg. Bytes Free per Page-每页上的平均可用字节数:所扫描的页上的平均可用字节数。越高说明有内部碎片,不过在你用这个数字决定是否有内部碎片之前,应该考虑fill factor(填充因子)。

  (9)Avg. Page Density (full)-平均页密度(完整):每页上的平均可用字节数的百分比的相反数。低的百分比说明有内部碎片。

  总结:(1)逻辑扫描碎片:越低越好 (2)平均页密度:80%左右最好,低于%60重建索引,(3)最佳计数与实际计数相差较大重建索引。

原文地址:https://www.cnblogs.com/MrHSR/p/9365114.html

时间: 2024-07-31 02:59:23

sql server 索引阐述系列五 索引参数与碎片的相关文章

SQL Server调优系列玩转篇三(利用索引提示(Hint)引导语句最大优化运行)

前言 本篇继续玩转模块的内容,关于索引在SQL Server的位置无须多言,本篇将分析如何利用Hint引导语句充分利用索引进行运行,同样,还是希望扎实掌握前面一系列的内容,才进入本模块的内容分析. 闲言少叙,进入本篇的内容. 技术准备 数据库版本为SQL Server2012,利用微软的以前的案例库(Northwind)进行分析,部分内容也会应用微软的另一个案例库AdventureWorks. 相信了解SQL Server的朋友,对这两个库都不会太陌生. 一.并行Hint提示 (MAXDOP N

SQL Server调优系列基础篇(索引运算总结)

原文:SQL Server调优系列基础篇(索引运算总结) 前言 上几篇文章我们介绍了如何查看查询计划.常用运算符的介绍.并行运算的方式,有兴趣的可以点击查看. 本篇将分析在SQL Server中,如何利用先有索引项进行查询性能优化,通过了解这些索引项的应用方式可以指导我们如何建立索引.调整我们的查询语句,达到性能优化的目的. 闲言少叙,进入本篇的正题. 技术准备 基于SQL Server2008R2版本,利用微软的一个更简洁的案例库(Northwind)进行解析. 简介 所谓的索引应用就是在我们

SQL Server调优系列进阶篇(如何索引调优)

前言 上一篇我们分析了数据库中的统计信息的作用,我们已经了解了数据库如何通过统计信息来掌控数据库中各个表的内容分布.不清楚的童鞋可以点击参考. 作为调优系列的文章,数据库的索引肯定是不能少的了,所以本篇我们就开始分析这块内容,关于索引的基础知识就不打算深入分析了,网上一搜一片片的,本篇更侧重的是一些实战项内容展示,希望通过本篇文章各位看官能在真正的场景中找到合适的解决方法足以. 对于索引的使用,我希望的是遇到问题找到合适的解决方法就可以,切勿乱用!!! 本篇在分析出索引的优越性的同时也将负面影响

SQL Server调优系列进阶篇(如何维护数据库索引)

原文:SQL Server调优系列进阶篇(如何维护数据库索引) 前言 上一篇我们研究了如何利用索引在数据库里面调优,简要的介绍了索引的原理,更重要的分析了如何选择索引以及索引的利弊项,有兴趣的可以点击查看. 本篇延续上一篇的内容,继续分析索引这块,侧重索引项的日常维护以及一些注意事项等. 闲言少叙,进入本篇的主题. 技术准备 数据库版本为SQL Server2012,前几篇文章用的是SQL Server2008RT,内容区别不大,利用微软的以前的案例库(Northwind)进行分析,部分内容也会

MS SQL Server:分区表、分区索引 详解

1. 分区表简介使用分区表的主要目的,是为了改善大型表以及具有各种访问模式的表的可伸缩性和可管理性. ?        大型表:数据量巨大的表.?        访问模式:因目的不同,需访问的不同的数据行集,每种目的的访问可以称之为一种访问模式. 分区一方面可以将数据分为更小.更易管理的部分,为提高性能起到一定的作用:另一方面,对于如果具有多个CPU的系统,分区可以是对表的操作通过并行的方式进行,这对于提升性能是非常有帮助的. 注意:只能在 SQL Server Enterprise Editi

《Pro SQL Server Internals》翻译之索引

本文选自<Pro SQL Server Internals> 作者: Dmitri Korotkevitch 出版社: Apress 出版年: 2016-12-29 页数: 804 作者简介:Dmitri Korotkevitchis是微软SQL Server MVP和微软认证大师.作为应用程序和数据库开发人员.数据库管理员和数据库架构师,他具有多年使用SQL Server的经验.他专门从事OLTP系统在高负载下的设计.开发和性能调优.Dmitri经常在各种Microsoft和SQL PASS

SQL Server 2016 —— 聚集列存储索引的功能增强

作者 Jonathan Allen,译者         邵思华         发布于     2015年6月14日 聚集列存储索引(CC Index)是SQL Server 2014中两大最引人瞩目的特性之一,设计为用于超过1千万条记录的数据表.使用者无需明确的指定索引,也能够保证分析式查询的优良性能. 但2014版本中的这一特性存在着一个缺陷,即使用者无法指定索引.虽然CC索引比起传统表的表扫描要快得多,但它还是及不上经手动调整的覆盖索引.因此,为了同时支持这两种模式,开发者不得不创建两张

SQL Server 查询性能优化——创建索引原则(一)

索引是什么?索引是提高查询性能的一个重要工具,索引就是把查询语句所需要的少量数据添加到索引分页中,这样访问数据时只要访问少数索引的分页就可以.但是索引对于提高查询性能也不是万能的,也不是建立越多的索引就越好.索引建少了,用WHERE子句找数据效率低,不利于查找数据.索引建多了,不利于新增.修改和删除等操作,因为做这些操作时,SQL SERVER除了要更新数据表本身,还要连带地立即更新所有的相关索引,而且过多的索引也会浪费硬盘空间.因此要建得恰到好处,这就需要经验了. 一:索引的基本目的 索引的基

SQL Server数据库性能优化之索引篇【转】

http://www.blogjava.net/allen-zhe/archive/2010/07/23/326966.html 性能优化之索引篇 近期项目需要, 做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能. 操作系统的性能,甚至网卡.交换机等.这篇文章主要讲到如何改善索引,还将有另一篇讨论