关于sql 的一些性能讨论

  1. SQL Server会将执行过的语句存入高速缓存中,因此理论上说使用带参数的语句会比使用常量的语句要快(因为每次语句相同,减少了语句分析和执行计划选择)。但如果参数赋予不同值时,返回的行数差异很大,这时选择相同的执行计划反而使一些查询变的异常慢。下面是f_parent_cateid赋予不同常量时得到的执行计划,它们各不相同,但如果使用参数方式,执行计划只会使用其中一种,取决于哪个被先执行。之前有测试过,如果A执行计划作为唯一选择时,f_parent_cateid=111将需要执行3分多钟(事实上选择B执行计划只要很短时间)。

2,Update时,无论更新的字段值是否改变,语句都会造成数据实际被修改(数据在硬盘上迁移),因此要避免无须修改的字段写在Update语句中,特别是那些索引组成字段(尤其是聚集索引组成字段)。

3,在一次查询中,并不是一张表只用一个索引,有时会采用两个索引连接得到结果。执行计划可以查看

4,   对于两张相对比较大的表,并且表行的数相近,执行计划有可能会选择嵌套循环连接两张表(原因不知),这时查询速度会异常的缓慢,比如两张100万级别的表,嵌套循环连接就相当于10000亿次(O(n^2))的比较(要出结果至少1小时以上)。当SQL Server错误的选择表连接方式时,应该将语句中的inner join强制改为inner hash join,直接使用Hash连接(O(n)),得到结果只要10到30秒。总之,如果遇到查询很慢时,应该优先查看一下是否是因执行计划选择错误造成的。

5,SQL Server(2008 及以前)目前还不支持跳跃式使用索引(Oracle支持),对于组合索引,必须按照索引中出现的字段顺序使用索引。如:由A和B组成的组合索引,如果A没出现在WHERE语句中(仅B),即使A的值只有两三种,也都无法使用上该组合索引。遇到这种情况可以考虑人为的加上辅助条件(加A条件),然后通过多次查询(取决A可能的值)返回结果。

6,如果两个表可以合在一张表,尽量将其合并,一个查询中越多表连接,就意味着越多的索引查找。尽管列较宽的表,索引查找成本会更高些(因为一页(8KB)存储的行数变少),但比起更多的索引查找,其成本还是小的多。

7,对于使用参数的语句或使用常量的语句,应保证其值类型与表中字段类型一致,否则有可能使用不上索引或分区列。对于整型常量,SQL Server默认认为是32位整型(即使64位的SQL Server也一样)。

时间: 2024-11-14 13:02:02

关于sql 的一些性能讨论的相关文章

SQL Server数据库性能优化之SQL语句篇(转载)

SQL Server数据库性能优化之SQL语句篇 原文地址:http://www.blogjava.net/allen-zhe/archive/2010/07/23/326927.html 期项目需要,做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主

利用pl/sql执行计划评估SQL语句的性能简析

一段SQL代码写好以后,可以通过查看SQL的执行计划,初步预测该SQL在运行时的性能好坏,尤其是在发现某个SQL语句的效率较差时,我们可以通过查看执行计划,分析出该SQL代码的问题所在. 那么,作为开发人员,怎么样比较简单的利用执行计划评估SQL语句的性能呢?总结如下步骤供大家参考: 1. 打开熟悉的查看工具:PL/SQL Developer. 在PL/SQL Developer中写好一段SQL代码后,按F5,PL/SQL Developer会自动打开执行计划窗口,显示该SQL的执行计划. 2.

最有效地优化 Microsoft SQL Server 的性能

为了最有效地优化 Microsoft SQL Server 的性能,您必须明确当情况不断变化时,性能将在哪些方面得到最大程度的改进,并集中分析这些方面.否则,在这些问题上您可能花费大量的时间和精力,而性能却得不到明显的改善. 以下大部分信息并不解决由多用户并发使用而引起的性能问题."Maximizing Database Consistency and Concurrency"(数据库一致性和并发性的最大化)一文以及其他知识库文章将对这个复杂的主题做单独的讨论,前者可从 SQL Ser

利用SET STATISTICS IO和SET STATISTICS TIME 优化SQL Server查询性能

首先需要说明的是这篇文章的内容并不是如何调节SQL Server查询性能的(有关这方面的内容能写一本书),而是如何在SQL Server查询性能的调节中利用SET STATISTICS IO和SET STATISTICS TIME这二条被经常忽略的Transact-SQL命令的. 从表面上看,查询性能的调节是一件十分简单的事.从本质上讲,我们希望查询的运行速度能够尽可能地快,无论是将查询运行的时间从10分钟缩减为1分钟,还是将运行的时间从2秒钟缩短为1秒种,我们最终的目标都是减少运行的时间. 尽

SQL Server数据库性能优化之SQL语句篇

SQL Server数据库性能优化之SQL语句篇 近期项目需要,做了一段时间的SQL Server性能优化,遇到了一些问题,也积累了一些经验,现总结一下,与君共享.SQL Server性能优化涉及到许多方面,如良好的系统和数据库设计,优质的SQL编写,合适的数据表索引设计,甚至各种硬件因素:网络性能.服务器的性能.操作系统的性能,甚至网卡.交换机等.这篇文章主要讲到如何改善SQL语句,还将有另一篇讨论如何改善索引.如何改善SQL语句的一些原则: 1. 按需索取字段,跟“SELECT *”说拜拜

Sql Server查询性能优化之走出索引的误区

据了解绝大多数开发人员对于索引的理解都是一知半解,局限于大多数日常工作没有机会.也什么没有必要去关心.了解索引,实在哪天某个查询太慢了找到查询条件建个索引就ok,哪天又有个查询慢了,再建立个索引就是,或者干脆把整个查询SQL直接发给DBA,让DBA直接帮忙优化了,所以造成的状况就是开发人员对于索引的理解.认识很局限,以下就把我个人对于索引的理解及浅薄认识和大家分享下,希望能解除一些大家的疑惑,一起走出索引的误区 误区1.在表上建立了索引,在查询时用到了索引的列,索引就一定会生效 首先明确下这样的

SQL Server 2008性能故障排查(一)——概论

原文:SQL Server 2008性能故障排查(一)--概论 备注:本人花了大量下班时间翻译,绝无抄袭,允许转载,但请注明出处.由于篇幅长,无法一篇博文全部说完,同时也没那么快全部翻译完,所以按章节发布.由于本人水平有限,翻译结果肯定存在问题,为了不造成误导,在每篇结尾处都附上原文,供大家参考,也希望能指出我的问题,以便改进.谢谢. 另外,本文写给稍微有经验的数据库开发人员或者DBA看,初学者可能会看不懂.在此请见谅 作者:Sunil Agarwal, Boris Baryshnikov, K

SQL Server 2008性能故障排查(二)——CPU

原文:SQL Server 2008性能故障排查(二)--CPU 承接上一篇:SQL Server 2008性能故障排查(一)--概论 说明一下,CSDN的博客编辑非常不人性化,我在word里面都排好了版,贴上来就乱得不成样了.建议CSDN改进这部分.也请大家关注内容不要关注排版.同时在翻译的过程中本人也整理了一次思路,所以还似乎非常愿意翻译,虽然有点自娱自乐,但是分享给大家也是件好事 CPU 瓶颈: CPU瓶颈可能因为某个负载所需的硬件资源不足而引起.但是过多的CPU使用通常可以通过查询优化(

SQL Server Profiler -- 性能调校

SQL Server Profiler -- 性能调校 性能有足够的理由成为一个热点话题.当今商业领域竞争激烈,如果用户认为某个应用程序速度太慢,就会立刻转向另一个供应商.为了满足用户的要求,SQL跟踪加载了一些事件类,可以利用这些事件类来查找和调试性能瓶颈. 性能监视技术可以大致分为两个类别:在已知故障相关知识时使用的技术和用来查找故障所在(或者查找到底是否存在故障)的技术.如果查出这个故障的某些问题,就可以在这方面获取更多的信息.因此,从第2种帮助精确定位故障区域的技术开始,然后再讨论怎样进