时不待我 天道酬勤

强者。

这条老牛，啥性能问题你都搞定了，顶！

一直对微软Entity FrameWork感兴趣，总是偷懒没去学习，改天要好好请教一下。

@刘鸿海 按照你的意思，如果elapsed time是整个查询时间，那么肯定不会出现CPU时间大于占用时间的。但实际上现在就是出现了这个情况，所以我们需要一个更官方的解释才行。

@jadesun 根据这段的意思elapsed time应该是整个查询的时间。因为根据他的说法，如果不需要查看CPU的时间的话那在语句前和后用getdate就可以了，如果你想比较整个查询时间和CPU时间的话要用这个选项。字面的意思也应该是整个查询的时间。

@刘鸿海 找了一下，有一段解释是这样的。可能不够官方 STATISTICS TIME The output of SET STATISTICS TIME ON is pretty self-explanatory. It shows the elapsed time and CPU time required to process the query. In this context, CPU time means the time not spent waiting for resources such as locks or reads to complete. The times are separated into two components: the time required to parse and compile the query, and the time required to execute the query. For some of your testing, you might find it just as useful to look at the system time with getdate before and after a query if all you need to measure is elapsed time. However, if you want to compare elapsed time vs. actual CPU time or if you're interested in how long compilation and optimization took, you must use STATISTICS TIME. In many cases, you'll notice that the output includes two sets of data for parse and compile time. This happens when the plan is being added to the plan cache for possible reuse. The first line is the actual parse and compile before placing the plan in cache, and the second line appears when SQL Server is retrieving the plan from cache. Subsequent executions will still show the same two lines, but if the plan is actually being reused, the parse and compile time for both lines will be 0.

@jadesun 抱歉，还得和你再讨论一下，呵呵。我的理解和你的理解不一样。 我感觉CPU时间应该只是单存的处理器时间片。 而占用时间应该是整个查询消耗的时间，包括CPU时间，IO，锁等待等时间。 但在msdn上查了下，没有找到官方详细说明。不知道你有没有。 但我做了个简单试验，验证了一下，应该是这样的。

CPU时间是等待锁等资源释放、解析、编译查询所需的处理器时间。 占用时间可以说是除了CPU时间之外，还有存储器中的数据存取,磁盘IO,总线上消耗的时间总和。 你怀疑的是CPU时间竟然大于占用时间？这个要问问比尔同学，如果不相信这个结果，我可以截图给你看看。然后你再找MS解释一下原因，再往下面深究我也不知道为什么了。

@jadesun 如果前面的提问中有什么语气不对的地方，请谅解。但是，难道别人就不能有疑问吗？如果都是一味的赞同和夸奖你认为你在博客里面会得到什么提高吗？难道你发博客的目的只是炫耀吗？如果你是这么认为的那可以忽视我下面的疑问。也可以忽视我上面所有的疑问。 我的疑问是：你是怎么理解CPU时间和占用时间的？CPU时间竟然大于占用时间。 [b]SQL Server 执行时间: CPU 时间 = 1641 毫秒，占用时间 = 633 毫秒[/b]。

@刘鸿海 原来的70多秒和现在的7、8秒，难道没有意义吗？非要叫真干什么？这里写的是我的工作日志，有必要自己吃饱了骗自己吗？

[quote]刘鸿海： @jadesun 才600毫秒吗？不知道你这个表tbCommonPart里面有多少数据，从结果来看，符合条件的就差不多有40万条。而且应该没有在这几个字段cnvcDeleteFlag='0' AND cnvcEndFlag <> '0' AND cnvcfiletype上设置的索引吧。 你这段是又单独执行的吧，有没有清缓存呢。[/quote] 清楚缓存你可以从上面的 "DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。“来看到我执行的语句 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 SQL Server 执行时间: CPU 时间 = 1641 毫秒，占用时间 = 633 毫秒。 (394871 行受影响) SQL Server 分析和编译时间: CPU 时间 = 313 毫秒，占用时间 = 1008 毫秒。 SQL Server 执行时间: CPU 时间 = 438 毫秒，占用时间 = 728 毫秒。 SQL Server 执行时间: CPU 时间 = 751 毫秒，占用时间 = 1736 毫秒。 (871 行受影响) SQL Server 执行时间: CPU 时间 = 1577 毫秒，占用时间 = 4977 毫秒。

@jadesun 才600毫秒吗？不知道你这个表tbCommonPart里面有多少数据，从结果来看，符合条件的就差不多有40万条。而且应该没有在这几个字段cnvcDeleteFlag='0' AND cnvcEndFlag <> '0' AND cnvcfiletype上设置的索引吧。 你这段是又单独执行的吧，有没有清缓存呢。

@刘鸿海 加入了，是600毫秒。只是在这儿没有贴出来

楼主优化后统计的时间只是单纯查询的时间啊，创建临时表的时间也要加上吧。而且这个时间应该也不短吧。

@Godot 原来是想定义一个BLL层的标准，但后来用BaseBLL实现了它。而后面所有的BLL都继承了BaseBLL。所以在这儿有一些多余了。

能否请教下，该框架里的IBaseBLL接口是干啥的?