（点击上方蓝字，快速关注我们)
前言： 在前面一文中，已经提到了三类常见的索引问
从上面描述可知，我们的步骤是： 注：这个步骤并不是必须的，也不是固定的，视实际情况而定才是最佳方案。下面来介绍整个流程。 起因：我们为什么要维护索引？大家都知道因为性能有问题了。为什么性能有问题呢？索引不合理了呗！绝大部分系统和IT从业人员都很难在一开始就做好性能规划。特别在国内这种赶项目进度，上线了再说的国情下，即使你知道这个功能有性能问题，但是修改会带来严重的项目延期的前提下，所有人都不会允许你做改动的。所以大部分性能问题都在系统运行到一定程度或者数据量突发增长或持续增长时才出现。甚至很多领导层认为：系统能用是最重要的，性能问题可以推一下。在这一些背景下，对开发、设计人员过多地指责他们没有做好前期工作是没必要的，大家将心比心，多点理解，对后面优化工作也有帮助，毕竟别人不会那么抵触。 那么在系统运行一段时间后出现性能问题或者运维压力时，你就要介入进行性能优化。性能优化的第一步并不是盲足乱搞，而是找瓶颈，找到瓶颈才能做相应的处理，否则只能听天由命，误打误撞的几率其实很小。下面我们假定系统的性能问题已经是索引引起的，那么我们就从定位瓶颈着手。 收集系统行为：我们知道，除非硬件BUG，否则一个静止的系统不会出现性能问题。所以系统的性能问题本质上是因为系统的行为导致的。因此，我们首先需要收集系统行为来定位瓶颈。 系统行为各式各样，又彼此关联，我们很难轻易地定位所有问题。但是Windows、SQL Server作为成熟的软件，在使用了十几年之后，业界已经有了一套比较成熟和现成的方案，所以我们不妨根据这些方案来收集。大概流程如下： 由于本文不是专门讨论如何侦测和处理系统性能问题的文章，所以非数据库部分只简略介绍。 首先，我们要做的是对基础的检测：服务器及操作系统的检查。服务器和操作系统是软件系统的支撑部分，并且一个软件系统的实际运行离不开对它们的准确、高效运作。上图中列出了“服务器型号”的检查，因为论坛上曾经有这么个帖子，一个新服务器安装SQL Server之后，服务一启动内存马上占满，期间没有任何操作。最后发现IBM x3650这款型号的服务器对SQL Server存在问题，换了其他型号之后就消失了。另外，对服务器特别是硬件的检查也是必要的，刚接手系统时，老是说卡，用性能计数器检测之后发现服务器的个别盘IO问题很严重，检查数据库文件存放路径之后发现，虽然服务器上有SSD盘，但是数据库依旧运行在服务器自带的SAS盘上，后来把用户库、TempDB移到SSD之后，虽然没有突飞猛涨的性能提升，但是再次检查可以得知大部分盘的IO使用情况已经趋向正常。我们知道，服务器对数据库性能影响最大的不是内存大小，而是IO。由于数据库不直接操作磁盘，而是把数据从磁盘加载到内存，所以磁盘的IO应该越快越好。简单来说，在操作系统和硬件配置合理的前提下，数据库文件应该按照各自行为存放在尽可能快的硬盘中。由于本文的主题在索引上，所以这里不多说。 对于操作系统配置，有几个点需要注意：
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
