在使用Entity Framework操作数据库时遇到的这个错误。

这个错误比较奇怪，在园子里看到一位兄弟写到有位大哥提出的原因是：http://www.cnblogs.com/plwang1990/articles/2025334.html

  sqlServer2008中提供datetime2类型的数据（比datetime更精确），而用entity framework4会默认的把C#中的
System.DateTime类转化成sqlServer2008中的datetime2类型，而你的数据库中的元素的属性设的是datetime类型，
把datetime2转化成datetime系统会认为会丢失数据，所以会报错。（感觉这TM是设计缺陷吧！这是熟么默认设置啊！）

经过调试发现，这位大哥说的当并不完全正确。SqlServer的datetime有效范围是1753 年 1 月 1 日到 9999 年 12 月 31 日，如果超出这个范围，EF就会把datetime转换为datetime2，也就是会出现上面的错误。

在点击google搜索结果时，google会在结果的URL前做个跳转，且有时这个跳转地址会被墙，这样极大的影响对搜索引擎的使用体验。

本方法只针对google chrome浏览器，解决方法很简单，因为chrome已经原生支持Greasemonkey脚本，所以只需要写下面一段脚本，然后导chrome既可：

var url = window.location.href.toLowerCase();
if (url.indexOf("www.google.com.hk") >= 0 || url.indexOf("/search") >= 0)
{
    var all = document.querySelectorAll("*");
    for (var i = 0; i < all.length; i ++)
    {
        all[i].onmousedown=null;
    }
}

先来对比两段分页SQL，假设条件：news表有15万记录，NewsTypeId=10有9万记录，当前查询NewsTypeID=10。那么，你会认为哪个SQL效率会高呢？

--代码一

DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT n.* FROM news AS n WITH(NOLOCK), #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize AND t.newsid=n.newsid
SELECT @cc
DROP TABLE #tb

--代码二
DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT NewsId INTO #tb2 FROM #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize
SELECT * FROM news WITH(NOLOCK) WHERE NewsId IN (SELECT * FROM #tb2)
SELECT @cc
DROP TABLE #tb
DROP TABLE #tb2

答案是代码二远远高于代码一。在代码一中加粗代码的操作会引起整表扫描，因为数据库引擎在认为WHERE表达式中满足条件记录大于一定阀值的时候，就不再去进行查询优化，而直接使用表扫描。看执行信息，：

表 'news'。扫描计数 1，逻辑读取 342 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(98361 行受影响)

(1 行受影响)

(40 行受影响)

表 '#tb________________________________________00000004C024'。扫描计数 1，逻辑读取 257 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 'news'。扫描计数 1，逻辑读取 2805 次，物理读取 0 次，预读 235 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

(1 行受影响)

原本，我想的执行计划，加粗部分的代码应该是聚焦索引查找，这样性能就提高很多。看代码二：

表 'news'。扫描计数 1，逻辑读取 342 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(98361 行受影响)

(1 行受影响)

表 '#tb____________________________________00000004BEEF'。扫描计数 1，逻辑读取 257 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(40 行受影响)

(1 行受影响)

(40 行受影响)

表 'news'。扫描计数 0，逻辑读取 131 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

表 '#tb2___________________________________00000004BEF0'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

(1 行受影响)

(1 行受影响)

很明显，代码二与代码一中的IO操作数大大降低。且代码一随着@PageIndex越来越大，效率会越来越低；但代码二的效率不会随@PageIndex变化而改变。

　　最近论坛更换为DiscuzNT，在对数据库监测过程发现[dnt_getindexforumlist]这个存储过程的lob逻辑读取次数过大，且等待时间也相对较长。查看存储过程源码发现，其实这个存储过程很简单，也就是dbo.dnt_forums和dbo.dnt_forumfields两个表关联查询。主要原因出现在dbo.dnt_forumfields这个表上，该表共有text和ntext类型字段10个。我们知道text是做为LOB对象来存储的，在实际的存储中，数据记录页上存储的是该字段的一个指针，真正的数据是存储在LOB数据页上。因此查询每一条记录时，都需要10次的IO来读取该字段的实际值。

　　解决方案很简单，只需要把text换为varchar(max)，把ntext换为nvarchar(max)既可。为什么这样就能减少IO次数，提高性能呢？因为，varchar(max)类型的实际长度如果在8000字节以下，这个值将被做为普通的varchar类型来处理，只有在长度超赤8000时，才被做为LOB对象来存储。

　　我们论坛的版块有290个，优化之后ＩＯ次数立马见分晓。

　　优化之前的IO信息：

表 'dnt_forumfields'。扫描计数 1，逻辑读取 77 次，物理读取 0 次，预读 0 次，lob 逻辑读取 5801 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'dnt_forums'。扫描计数 2，逻辑读取 298 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。

　　优化之后的IO信息：

表 'dnt_forumfields'。扫描计数 1，逻辑读取 2 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'Worktable'。扫描计数 0，逻辑读取 0 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。
表 'dnt_forums'。扫描计数 2，逻辑读取 298 次，物理读取 0 次，预读 0 次，lob 逻辑读取 0 次，lob 物理读取 0 次，lob 预读 0 次。