广

MSSQL

  • MYSQL
  • MSSQL
  • Redis
  • MongoDB
  • oracle数据库
  • 数据管理

    SQLServer2005重建索引前后对比分析

    2018-05-07 10:24:19 次阅读 稿源:互联网
    零七网广告
    全网推广平台,软文发布
    在做维护项目的时,我们经常会遇到索引维护的问题,通过语句,我们就可以判断某个表的索引是否需要重建。

    执行一下语句:先分析表的索引

    分析表的索引建立情况: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%

    零七网部分新闻及文章转载自互联网,供读者交流和学习,若有涉及作者版权等问题请及时与我们联系,以便更正、删除或按规定办理。感谢所有提供资讯的网站,欢迎各类媒体与零七网进行文章共享合作。

    零七网广告
    零七网广告
    零七网广告
    零七网广告