SQL索引重建

        前2周出现一件怪异的事情。一个新版本下发到生产环境之后，某个岗位的某个页面展示异常的慢，展示达到了20秒，提交一笔页面则达到了10秒......

        问题都是这样，当你过后觉得十分十分十分的简单，但是当时对你来说简直是晕头转向，一方面是行方不断追问，另一方面是业务人员电话都要打爆的质疑。在这样环境下你需要的是冷静的思考和逻辑的推断去排查问题。

        在排除了服务器CPU，内存使用率瓶劲的可能之后，问题就集中在了数据库查询身上。联系业务部分和科技人员部分密码管理员打开数据库的Admin权限，使用查询事件探查器（SQL-Profiler）。再联系一个业务在本地直接用LocalHost登入获取页面，同时执行SQL-Profiler，真的有新发现：发现该页面执行某条语句去查询某张View的时候十分的慢，Duration达到了9000+，即9秒多。

       这时候想起这次版本下发，针对这张View下的一个Table进行了全部删除再导入数据的操作（之前由于某些原因导致该表数据冗余，达到了原表大小的3倍，10W多条的记录，导入的数据来自和生产环境一样的SIT环境）。但是没有考虑到对Table进行索引重构。马上要求发起业务维护申请，对该View下面的2个Table进行ReIndex：

     DBCC DBREINDEX (TableName1,Index_Name1)
     DBCC DBREINDEX (TableName1,Index_Name2)
     DBCC INDEXDEFRAG (TableName2,Index_Name3)
     DBCC INDEXDEFRAG (TableName2,Index_Name4)

     UPDATE STATISTICS TableName1
     UPDATE STATISTICS TableName2

 

    执行语句之后，该岗位业务恢复正常。一下是摘自网上文章：

 

 

解决碎片问题

一旦你确定表或索引有碎片问题，那么你有4个选择去解决那些问题：

1.