学习笔记(十一)——数据库的索引碎片、计划缓存、统计信息

1.索引碎片sql

数据库存储自己是无序的,创建了汇集索引,会按照汇集索引物理顺序存入硬盘。既键值的逻辑顺序决定了表中相应行的物理顺序数据库

并且在大多数的状况下,数据库写入频率远低于读取频率,索引的存在为了读取速度牺牲写入速度(页 为最小单位 8kb,区 物理连续的页(8页)的集合)缓存

其内部碎片 数据库页内部产生的碎片,外部反之。函数

询碎片状况:优化

  1.  dbcc showcontig:四部分对象名,【索引名】|【索引id】
  2.  dbcc showcontig:当前库对象id,【索引名】|【索引id】    
  3.    sys.dm_db_index_physical_stats:数据库id,对象id,索引id,分区id,扫描模式 ‘

实例:server

显示数据库里全部索引的碎片信息对象

SET NOCOUNT ONblog

USE pubs排序

DBCC SHOWCONTIG WITH ALL_INDEXES索引

GO

 

显示指定表的全部索引的碎片信息

SET NOCOUNT ONUSE pubs

DBCC SHOWCONTIG (authors) WITH ALL_INDEXES

GO

 

显示指定索引的碎片信息

SET NOCOUNT ON

USE pubs

DBCC SHOWCONTIG (authors,aunmind)

GO

2.计划缓存

平时所写的SQL语句本质只是获取数据的逻辑,而不是获取数据的物理路径。当咱们写的SQL语句传到SQL Server的时候,查询分析器会将语句依次进行解析(Parse)、绑定(Bind)、查询优化(Optimization,有时候也被称为简化)、执行(Execution)。除去执行步骤外,前三个步骤以后就生成了执行计划,也就是SQL Server按照该计划获取物理数据方式,最后执行步骤按照执行计划执行查询从而得到结果。但查询优化器不是本篇的重点,本篇文章主要讲述查询优化器在生成执行计划以后,缓存执行计划的相关机制以及常见问题。

 1: SELECT * 
   2: FROM A INNER JOIN B ON a.a=b.b
  3: INNER JOIN C ON c.c=a.a

 实例:

经过动态管理视图和函数,查看当前缓存的全部执行计划
	       SELECT/*PlanCache*/			
		ISNULL(QS.execution_count,0) AS ExecutionCount
		,CP.usecounts AS LookupCount
		,CP.objtype AS ObjectType
		,ST.text AS Sql		
		,QP.query_plan AS QueryPlan
	FROM				
		sys.dm_exec_cached_plans AS CP
		LEFT JOIN sys.dm_exec_query_stats AS QS ON CP.plan_handle=QS.plan_handle
		CROSS APPLY sys.dm_exec_sql_text(CP.plan_handle) AS ST
		CROSS APPLY sys.dm_exec_query_plan(CP.plan_handle) AS QP
	WHERE				
		ST.text NOT LIKE 'SELECT/*PlanCache*/%'
	ORDER BY				
		QS.last_execution_time ASC;

 

3.统计信息

Sqlserver 查询是基于开销查询的,在首次生成执行计划时,是基于多阶段的分析优化才肯定出较好的执行计划。而这些开销的基数估计,是根据统计信息来肯定的。统计信息其实就是对表的各个字段的整体数据进行分段分布,数据库默认都会自动维护。

表和视图都有统计信息,统计信息对象是根据索引或表列的列表建立的。当某列第一次最为条件查询时,将建立单列的统计信息。当建立索引时,将建立同名的统计信息。索引中,统计信息只统计首列,所以索引除了按首列排序存储数据外,其统计信息也是按首列计算统计的,因此索引设置时定义的第一列很是重要。每一个统计信息对象都在包含一个或多个表列的列表上建立,而且包括显示值在第一列中的分布的直方图。

实例:

SELECT 	
		O.* 
	FROM 
		tb_Order2 AS O 
	WHERE 
                O.CustomerLastName='Adams';	

 

相关文章
相关标签/搜索