金色海洋同学的"关于Int自增字段和GUID字段的性能测试"
原文：关于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%
附：不好意思，刚没看到有好几篇帖子在讨论这个话题，可能这些看法大家已经讨论到了
