摘要: 前段时间提到的"SQL Server 2005 死锁解决探索",死锁严重,平均每天会发生一次死锁,在解决和处理SQL server2005死锁中查了很多资料和想了很多办法, 对为何出现死锁和怎样较少死锁有了进一步认识,在这里和大家一起分享: SQL Server 锁类型 在数据库中主要存在两种锁: S(共享锁)和X(排他锁) S(共享锁):在执行查询数据时,SQL server会将行锁定,这时只能...
阅读全文
摘要: 当我们优化一个系统时,有时发现一种情况就是自己修改SQL,索引以及分区是不能解决性能问题的。这时你要考虑业务逻辑优化和表设计的重构。这两点的确和设计结合的很紧密。 业务逻辑优化 结合实际,我们先谈谈业务逻辑优化。 案例一:我们的系统一个文档模块,客户点击时很慢,通过性能分析,是点击是去查询数据库,这时系统是通过Hibernate来两步处理: 1,计算该类型的文档数量总数。 2,显示最新文档的前20...
阅读全文
摘要: 今天在itput上看了一篇文章,是讨论一个语句的优化: 原贴地址: http://www.itpub.net/viewthread.php?tid=1015964&extra=&page=1 一,发现问题 优化的语句: [代码] 以上就是优化的需要优化的语句和情况。 不少人在后面跟帖:有的说没办法优化,有的说将IN该为EXISTS,有的说在ip上建立索引复合索引(ip,name)等...
阅读全文
摘要: 这是SQL Server 2005里的介绍:如果两个联接输入都很大,而且这两个输入的大小差不多,则预先排序的合并联接提供的性能与哈希联接相近。但是,如果这两个输入的大小相差很大,则哈希联接操作通常快得多。 哈希联接可以有效处理未排序的大型非索引输入。它们对复杂查询的中间结果很有用,因为: ·中间结果未经索引(除非已经显式保存到磁盘上然后创建索引),而且通常不为查询计划中的下一个操作进行适...
阅读全文
摘要: 简介:如果两个联接输入并不小但已在二者联接列上排序(例如,如果它们是通过扫描已排序的索引获得的),则合并联接是最快的联接操作。如果两个联接输入都很大,而且这两个输入的大小差不多,则预先排序的合并联接提供的性能与哈希联接相近。从上次我们分析来看,嵌套循环适合输入和输出都小的情况,那如果输入和输入都比较大情况下,使用合并算法什么情况下最优。最佳使用:合并联接本身的速度很快,但如果需要排序操作,选择合并...
阅读全文
摘要: 前段时间看了一篇关于算法的blog,地址如下: http://www.cnblogs.com/perfectdesign/archive/2008/04/24/sql_tuning.html 不少人也给了解决方法,以前也研究过(嵌套,合并,hash)算法,但没有真正的用到优化中,这个例子给了我很大启示。 现在就讨论一下这三个算法的使用。 嵌套循环:算法:for each row R1 in the...
阅读全文
摘要: 在使用Exists时,如果能正确使用,有时会提高查询速度: 1,使用Exists代替inner join 2,使用Exists代替 in 1,使用Exists代替inner join例子: 在一般写sql语句时通常会遇到如下语句: 两个表连接时,取一个表的数据,一般的写法通过关联查询(inner join): [代码]查询结果:[代码] 还有一种写法使用exists来取数据[代码]执行结果: [代...
阅读全文
摘要: 由于Oracel 10g 是一个多进程多线程的数据库,而SQL server是一个单进程多线程的数据库Oracel实例主要有3类进程 1,服务器进程 2,后台进程3,从属进程 服务器进程:分为专有服务器进程和共享服务器进程 后台进程: 1,PMON(进程监视器) 该进程是在出现异常中止后完成操作,还包括监视其他后台进程,如果这些进程崩溃,他来负责重启进程。PMON还会向Oracle TNS 监听...
阅读全文