SQL SEVER数据库重建索引的方法
1.想要判断数据库查询缓慢的问题，可以使用如下语句，可以列出查询语句的平均时间，总时间，所用的CPU时间等信息
,last_execution_time N'上次执行时间'
,total_physical_reads N'物理读取总次数'
,total_logical_reads/execution_count N'每次逻辑读次数'
,total_logical_reads N'逻辑读取总次数'
,total_logical_writes N'逻辑写入总次数'
, execution_count N'执行次数'
, total_worker_time/1000 N'所用的CPU总时间ms'
, total_elapsed_time/1000 N'总花费时间ms'
, (total_elapsed_time / execution_count)/1000 N'平均时间ms'
,SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1) N'执行语句'
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
where SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,
((CASE statement_end_offset
WHEN -1 THEN DATALENGTH(st.text)
ELSE qs.statement_end_offset END
- qs.statement_start_offset)/2) + 1) not like'%fetch%'
ORDER BY total_elapsed_time / execution_count DESC;
2.列出数据库每个表的数据量，并且需要运维人员对业务足够了解，知道大概哪些表是查询量最多的，可以查看“排在前面的表的磁盘使用情况”：
3.查看表碎片的情况，可以使用命令
DBCC SHOWCONTIG
可以看到该表扫描密度只有33.52%（最佳状态是100%，每个表页都写满数据），远远低于最佳计数，也就是说这个表的利用率很低，本来扫描一页 就能出结果，现在可能需要扫描三页，增加了查询时间；而逻辑碎片和区碎片都很多（一般认为超过30%就需要优化了），也就是说同样一页，数据很少而碎片很 多，占用了过多的数据库资源。
4.根据你对业务的了解，找出查询最多的表，对比他的数据，查询时间，和碎片程度可以判断出该表是否需要整理碎片，重建索引，以提高数据库性能。
重建索引的语句为：
use[数据库名]
ALTER INDEX ALL ON [表名称] REBUILD;
重建后，同样的一张表NWME_Company_Index，再次查询表碎片情况的结果如下：
可以看到密度已经变为96.9%，而逻辑碎片几乎没有了。
5.现在可以看一下整理碎片后，是否真的对查询性能优化了，再次运行第一点列出的命令查看可以发现，大部分查询语句所用的平均时间都下降了接近一半：
现在可以到前台实际体验优化后的效果了。
在做维护项目的时，我们经常会遇到索引维护的问题，通过语句，我们就可以判断某个表的索引是否需要重建。
执行一下语句：先分析表的索引
分析表的索引建立情况：DBCC showcontig('Table')
DBCC SHOWCONTIG 正在扫描 'Table'' 表...
表: 'Table'' (53575229)；索引 ID: 1，数据库 ID: 14
已执行 TABLE 级别的扫描。
- 扫描页数................................: 228
- 扫描区数..............................: 52
- 区切换次数..............................: 225
- 每个区的平均页数........................: 4.4
- 扫描密度 [最佳计数:实际计数].......: 12.83% [29:226]
- 逻辑扫描碎片 ..................: 97.37%
- 区扫描碎片 ..................: 98.08%
- 每页的平均可用字节数........................: 2686.3
- 平均页密度(满).....................: 66.81%
当你发现，扫描密度行，最佳计数和实际计数的比例已经严重失调，逻辑扫描碎片占了非常大的百分比，每页平均可用字节数非常大时，就说明
你的索引需要重新整理一下了。
执行重建索引命令：
DBCC DBREINDEX('Table'')
后分析的情况
DBCC SHOWCONTIG 正在扫描 'Table'' 表...
表: 'Table'' (53575229)；索引 ID: 1，数据库 ID: 14
已执行 TABLE 级别的扫描。
- 扫描页数................................: 154
- 扫描区数..............................: 20
- 区切换次数..............................: 19
- 每个区的平均页数........................: 7.7
- 扫描密度 [最佳计数:实际计数].......: 100.00% [20:20]
- 逻辑扫描碎片 ..................: 0.00%
- 区扫描碎片 ..................: 55.00%
- 每页的平均可用字节数........................: 86.8
- 平均页密度(满).....................: 98.93%
