浅析SQL SERVER数据库性能调优

SQL Server是一个非常成功的数据库服务器，它在自调教（self-tuning）方面非同一般。即装即用的SQL Server做了大量的工作以良好的运行，而且可以在完全无须用户配置的条件下提供极佳的性能。然而随着数据量日积月累不断的增长，那些在系统测试初期运行流畅的报表和数据传输软件开始出现运行缓慢甚至是停滞的现象。这时，一个新的任务摆在我们面前，那就是“数据库性能调优”。它其实并不是一项深奥的艺术，而是一门聚焦性很强的科学。只要掌握了系统的方法﹑适当的工具以及恰当的知识，任何对SQL Server有基本了解的人都能通过逐步采取措施来提高数据库系统的性能。下面笔者就从日常实际工作中选取两个案例来对”性能调优”展开分析讨论。

当前我们公司的数据运行环境由车道本地表，站级数据库，路段中心数据库，区域中心数据库组成，数据逐级上传，层层备份。但是由于日常实际应用的需要，路段中心数据库上的用户很多，性能开销很大。一段时间以来数据库用户反映数据库运行缓慢，甚至无法工作。通过查看SQL Server的“企业管理器”中的“锁∕进程ID”发现出现了阻塞。在这里简单对阻塞这个术语加以解释。数据库系统为了解决并发性控制的问题，所以对于访问的数据库资源通过加锁来保证隔离级别和一致性。某个进程访问某个资源时将对该资源加锁，访问完成后释放锁。当一个进程对访问的资源还没有释放锁时另一个进程又来访问相同的资源，这时就会出现阻塞。按照这个思路，经过逐表分析检查，发现出口流水表写入数据很慢，插入1条数据平均用时12秒!难怪数据库用户无法正常工作。 因为在一个高并发性的数据环境中这12秒足以造成严重阻塞。进一步检查发现出口流水表上有一个触发器，而这个触发器的任务非常繁重，包括判断是否手工输入流水，用以确定数据流向。按月﹑日﹑小时分类统计出口流水记录并插入相应的统计表。生成特殊事件流水表。生成数据完整性比较表。通行卡动态表等一系列任务。而其中任何一个环节出现的缓慢都会导致整个事务提交速度的延迟。通过逐段分步的分析测试，最终将问题定位在通行卡动态表上。数据库经过几年的运行，通行卡动态表里已经有220余万条数据了。而触发器对通行卡动态表访问的两个查询条件中的通行卡卡号字段居然没有建立“索引”。“索引”用于提供对数据的快速访问，它经常是调校一个系统时查看的第一个方面。如果一个查询条件没有建立索引则意味着进行一次全表扫描，这对于1万条数据的数据表来说速度是很快的，而对于220万条数据来说将会导致系统反应性能下降，大量的系统资源消耗在这个不恰当的查询条件上，直接造成阻塞。解决方案是在“通行卡卡号“字段上建立一个非聚簇索引（因为通行卡动态表上已经有一个聚簇索引），再查看出口流水表插入数据的速度为0.4秒，使得系统的并发性和系统资源消耗都达到了一个比较理想的状态，至此问题得到解决。

某天有用户反映“收费站员工收费差错汇总 ”报表打不开了。经过仔细分析，发现报表所指向的视图打开时连接超时。视图可以被看成是虚拟表或存储查询。可通过视图访问的数据不作为独特的对象存储在数据库内。数据库内存储的是 SELECT 语句。SELECT 语句的结果集构成视图所返回的虚拟表。它有以下优点：简单性。视图不仅可以简化用户对数据的理解，也可以简化他们的操作。安全性。通过视图用户只能查询和修改他们所能见到的数据。数据库中的其他数据则既看不见也取不到。逻辑数据性。视图可以使应用程序和数据库表在一定程度上。如果没有视图，应用一定是建立在表上的。有了视图之后，程序可以建立在视图之上，从而程序与数据库表被视图分割开来。同时也存在一些缺点：性能：SQL Server必须把视图的查询转化成对基本表的查询，如果这个视图是由一个复杂的多表查询所定义，那么，即使是视图的一个简单查询，SQL Server也把它变成一个复杂的结合体，需要花费一定的时间。修改：当用户试图修改视图的某些行时，SQL Server必须把它转化为对基本表的某些行的修改。对于简单视图来说，这是很方便的，但是，对于比较复杂的视图，可能是不可修改的。而本例中导致查询超时的根本原因，是因为数据量太大（其中出口流水表数据量达到千万级，出口流水统计表也达到了百万级）而视图是把3个表全表合并，然后再通过查询将符合条件的数据反馈给用户，这里有大量的系统资源耗费在全表合并上。找到了导致问题的原因，应对的解决方案是在3个表连接之前就通过聚簇索引查询把数据量缩小到一个时间范围内，然后再将3个有了具体时间范围的数据合并，这样就大大提高了查询效率。修改后再测试报表，按月统计汇总可以在3秒左右查询出数据，系统运行达到比较合理的状态。

以上两个例子，都是因为在收费站开通初期数据量很小的情况下测试通过的软件，随着时间的推移，性能随着数据量逐渐增长而逐渐下降，一些漏洞也暴露了出来。通过“数据库性能调优”技术，可以降低系统资源的消耗，提高用户的工作效率。而这又需要我们运用扎实的数据库理论基础和正确的分析方法在实际运行环境中去不断地尝试和验证。也是数据库系统分析员的基本工作。以上是本人对“数据库性能调优”的一些粗浅见解，还希望各路段同行批评和指导。