金色海洋同学的"关于Int自增字段和GUID字段的性能测试"
2009-08-01 21:41
344 查看
原文:关于Int自增字段和GUID字段的性能测试。只有测试,没有分析,呵呵
1. 为什么加了top之后执行计划变得不一样了?
加了top 100后,因为只需要返回100条数据,2个表之间的关联有索引信息,sql server可以优化执行计划,使用了nested loop方法
没加top 100需要返回所有数据,因为数据比较多sql server评估出来成本比较高,电脑是双核的,因此采用了并行的执行计划。并行执行会多出很多操作,sql server需要分区,执行完了需要合并结果,但这样可能使执行时间变短(不是绝对的,有的情况下比非并行的时间还要长)
2. 为什么用int identity速度没有明显快起来?
速度 != 效率,效率是一个综合性的考量因素。可以举一个简单的例子,假如在一台单CPU的机器上:
a). sql A执行时CPU使用率25%,需要的时间为2秒
b). sql B执行时CPU使用率10%,需要的时间为4秒
请问理想情况下平均每10秒时间,a)和b)最大处理请求数分别为多少?(a 20, b 25)
效率反映出来的、比较直观的结果就是对吞吐量、数据量的支持,我们开发的程序不只是一个人用,很多时候写出来的语句可能很快,但这并不一定意味着效率好,并发请求在50、100、1000的时候会怎么样?数据量在10万、100万、1000万的时候会怎么样?
sql语句对CPU、内存、I/O的使用是几个主要考量点,用sql server profiler监控sql语句的执行,可以看到CPU、Reads、Writes、Duration几个数据,通常sql server profiler加上执行计划所反映出来的信息基本够用了,更详细的监控分析可以使用系统的performance monitor
我对这个测试的看法:
1. 5万 join 20万,以及返回20万数据,本身这个成本不小,至于主键是int、guid,还是varchar之类的,执行时间差别不会太大
2. 因为不同类型的主键之间差别不会太大,而sql server本身存在多任务调度、内存管理,加上windows系统这个多任务环境,可能还有大量其他因素的干扰,例如杀毒软件对文件、内存的监控等,不可能得出一个谁比谁快的问题,多测几次,关掉其他程序或者重启机器后测试,或者别人拿着同样的数据库进行测试,反映出来的结果可能都会不一样
3. 用sql profiler看看CPU、Reads、Writes、Duration之间的差别,可以得到稍微具体详细,以及全面一点的对比评估。他们之间没有一个比另一个好的说法,权衡使用而已。效率、性能、设计等等都是在权衡取舍之间做决策
4. guid的主键,性能方面更多的是综合考虑存储结构、索引和数据页碎片问题、insert时的效率问题
3. 为什么CPU使用率非常低,sql server却长时间不返回数据,sql server在干什么?
首先得根据查询计划看使用的是什么join方法,通常,Nested Loop/Inner Join这样的操作CPU和内存使用都比较低,而Hash Match/Inner Join这样的操作运算量很多CPU占用高,内存要求由操作的数据量确定。统计信息不准等一些因素的影响,有可能导致sql server在不适合使用nested loop的情况下使用了他,这就出现CPU占用很低而查询语句需要执行很久
详细的join方法说明可以参考通往性能优化的天堂-地狱 JOIN方法说明
如果使用的是Hash Match/Inner Join,CPU使用率低,很可能是在等I/O,可能原因是sql server能够使用的内存不够,或者I/O本身比较慢,只要内存足够数据都能加载到内存,并且数据量不是太小,Hash Match的CPU使用率通常在80-100%
附:不好意思,刚没看到有好几篇帖子在讨论这个话题,可能这些看法大家已经讨论到了
1. 为什么加了top之后执行计划变得不一样了?
加了top 100后,因为只需要返回100条数据,2个表之间的关联有索引信息,sql server可以优化执行计划,使用了nested loop方法
没加top 100需要返回所有数据,因为数据比较多sql server评估出来成本比较高,电脑是双核的,因此采用了并行的执行计划。并行执行会多出很多操作,sql server需要分区,执行完了需要合并结果,但这样可能使执行时间变短(不是绝对的,有的情况下比非并行的时间还要长)
2. 为什么用int identity速度没有明显快起来?
速度 != 效率,效率是一个综合性的考量因素。可以举一个简单的例子,假如在一台单CPU的机器上:
a). sql A执行时CPU使用率25%,需要的时间为2秒
b). sql B执行时CPU使用率10%,需要的时间为4秒
请问理想情况下平均每10秒时间,a)和b)最大处理请求数分别为多少?(a 20, b 25)
效率反映出来的、比较直观的结果就是对吞吐量、数据量的支持,我们开发的程序不只是一个人用,很多时候写出来的语句可能很快,但这并不一定意味着效率好,并发请求在50、100、1000的时候会怎么样?数据量在10万、100万、1000万的时候会怎么样?
sql语句对CPU、内存、I/O的使用是几个主要考量点,用sql server profiler监控sql语句的执行,可以看到CPU、Reads、Writes、Duration几个数据,通常sql server profiler加上执行计划所反映出来的信息基本够用了,更详细的监控分析可以使用系统的performance monitor
我对这个测试的看法:
1. 5万 join 20万,以及返回20万数据,本身这个成本不小,至于主键是int、guid,还是varchar之类的,执行时间差别不会太大
2. 因为不同类型的主键之间差别不会太大,而sql server本身存在多任务调度、内存管理,加上windows系统这个多任务环境,可能还有大量其他因素的干扰,例如杀毒软件对文件、内存的监控等,不可能得出一个谁比谁快的问题,多测几次,关掉其他程序或者重启机器后测试,或者别人拿着同样的数据库进行测试,反映出来的结果可能都会不一样
3. 用sql profiler看看CPU、Reads、Writes、Duration之间的差别,可以得到稍微具体详细,以及全面一点的对比评估。他们之间没有一个比另一个好的说法,权衡使用而已。效率、性能、设计等等都是在权衡取舍之间做决策
4. guid的主键,性能方面更多的是综合考虑存储结构、索引和数据页碎片问题、insert时的效率问题
3. 为什么CPU使用率非常低,sql server却长时间不返回数据,sql server在干什么?
首先得根据查询计划看使用的是什么join方法,通常,Nested Loop/Inner Join这样的操作CPU和内存使用都比较低,而Hash Match/Inner Join这样的操作运算量很多CPU占用高,内存要求由操作的数据量确定。统计信息不准等一些因素的影响,有可能导致sql server在不适合使用nested loop的情况下使用了他,这就出现CPU占用很低而查询语句需要执行很久
详细的join方法说明可以参考通往性能优化的天堂-地狱 JOIN方法说明
如果使用的是Hash Match/Inner Join,CPU使用率低,很可能是在等I/O,可能原因是sql server能够使用的内存不够,或者I/O本身比较慢,只要内存足够数据都能加载到内存,并且数据量不是太小,Hash Match的CPU使用率通常在80-100%
附:不好意思,刚没看到有好几篇帖子在讨论这个话题,可能这些看法大家已经讨论到了
相关文章推荐
- 关于Int自增字段和GUID字段的性能测试。只有测试,没有分析,呵呵
- 关于Int自增字段和GUID字段的性能测试。只有测试,没有分析,呵呵
- 关于侯垒的自增字段和GUID字段性能对比文章的一些自己的分析(没有测试,纯粹分析)
- MySql中测试GUID 与Int自增主键 性能对比 总结适用场景
- 关于INT、GUID与COMB在使用效率上的测试
- jmeter性能测试,基于scf框架的"java请求"接口封装、环境配置与测试
- 关于"parseInt"
- 关于数据库字段长度对于查询性能的小测试
- 关于"parseInt"
- 使用GUID作为数据库主键与INT作为主键的性能测试
- 关于数据库字段长度对于查询性能的小测试
- 关于 ASP.NET 的 CompilationMode="Never" 性能问题
- 关于Java中的"=="、equals和"="
- 关于"Can't find..."*.pch"或"stdafx.h"的解决方法
- oracle修改字段类型时报"要更改的列必须为空"处理方法
- 关于实体为Date类型的字段,如何用model.find(" date>? ",param)方法进行查询?
- 关于Expression Tree和IL Emit的所谓的"性能差别"
- 关于"Get&Post"——千里码(4)
- 关于正则表达式 g,m 参数的总结,为了回答“正则表达式(/[^0-9]/g,'')中的"/g"是什么意思?”
- [性能测试]关于性能测试的一些建议