我总是采用首先使用最少的索引集部署数据库,然后根据性能指示添加/更改索引的方法.
这种方法运作得相当好.但是,它仍然没有告诉我在哪里可以提高性能.它只告诉我性能如此糟糕以至于用户抱怨它.
目前,我正在为许多应用程序重构数据库对象.
因此,我不应该费心寻求性能改进,因为"过早优化是所有邪恶的根源"吗？
在重构应用程序代码时,开发人员一直在寻找提高代码质量的方法.有没有办法不断寻求数据库性能的改进？如果是这样,您发现哪些工具和技术最有帮助？
我曾简要介绍过"数据库引擎调优顾问",但没有发现它有用.也许我只需要更多的经验来解释结果.
我的方法是使用SQL Server Profiler将针对服务器或数据库的命令收集到表中.完成后,您可以根据max和avg执行时间,max和avg cpu时间以及(也非常重要)查询运行的次数进行查询.
由于我尝试将所有数据库访问代码放在存储过程中,因此我很容易打破查询.如果使用内联SQL可能会更难,因为更改查询中的值会使其看起来像一个不同的查询.您可以尝试使用LIKE运算符解决此问题,将相同类型的查询放入相同的存储区中以计算聚合(max,avg,count).
一旦你有一个潜在问题的"前10名"列表,你可以开始单独查看它们,看看是否可以重新编写查询,索引可能有所帮助,或者是否需要进行次要的架构更改.要想出前十名,请尝试以不同的方式查看数据:平均值*平均值计算期间的总成本,最差的罪犯,平均值等等.
最后,如有必要,请务必在不同时间段进行监控.每个人进入和运行他们的每日报告时的数据库使用情况可能与用户输入新数据时的中午不同.您也可以决定,即使某个夜间进程比任何其他查询花费的时间更长也无关紧要,因为它在非工作时间运行.
祝好运!
"过早优化是万恶之源"
在数据库编程方面,我认为这句话是无稽之谈.重写整个应用程序是非常昂贵的,因为开发人员并不关心第一次编写有效的代码.所有t-sql代码都应该考虑它将如何影响数据库性能(数据完整性当然是第一个).除了数据完整性之外,性能应该胜过一切.
是的,在遇到问题之前,你不应该做一些优化的事情,但有些事情应该是理所当然的,而不是以后修复的.编写具有更高效率的代码的代码不会花费更多的时间,一旦您了解了如何通过错误的代码影响效率,就不会有这样的代码.Cervo对游标代码的讨论就是一个例子.基于集合的操作几乎总是比游标解决方案快得多,因此在基于集合的解决方案时,不应该首先编写游标.它几乎总是花费我更少的时间来编写一个基于集合的解决方案来编写游标,但是获得这种方式的唯一方法就是永远不要编写游标.
并且没有理由使用select*而不是指定您的字段名称.在MSSQL中,您可以将这些名称从对象资源管理器中拖出来,这样您就无法告诉我这样做太难了.但是,通过仅指定实际需要的字段,可以节省网络资源和数据库服务器资源以及Web服务器资源.那么为什么程序员应该选择*的懒惰选项并担心以后的优化呢？
与索引相同的事情.你说你做了一组最小的索引.根据你如何定义minimal,这可能没问题,但是在所有外键上都有索引是至关重要的,我不想推送一个没有索引的数据库,这些数据通常位于最常见的几个字段中条款.如果您的用户不在内部而非内部,他们不会抱怨您的网站有多慢,他们会去其他地方.它只是从一开始就计划有效的数据库访问使总线感觉.
关于未能从一开始就考虑效率的主要担忧之一是,前几次事情太慢,公司倾向于在问题上投入更多设备而不是性能调整.当人们开始进行性能调整时,你就拥有了几千兆字节或更多的数据库,其中许多不满意的客户获得超时而不是结果.此时,通常几乎所有数据库中的内容都必须重写,与此同时,您正在失去客户.我记得在一家拥有商业应用程序的公司提供支持时,客户服务代表需要花费十分钟时间从一个屏幕移动到另一个屏幕,同时他们试图通过电话帮助已经心怀不满的客户.
SQL Server执行计划!!! 请访问:http://dbalink.wordpress.com/2008/08/08/dissecting-sql-server-execution-plans-free-ebook/
京公网安备 11010802040832号 | 京ICP备19059560号-6 