LINQ to SQL:处理char(1)字段的方式会引起全表扫描问题

前端之家收集整理的这篇文章主要介绍了LINQ to SQL:处理char(1)字段的方式会引起全表扫描问题前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

image

如果表中的字段类型为 char(1) 时,Linq to sql生成char (System.Char)的属性,如下图

image image
表定义 生成的实体

2.

如果要查询LineCode=='A'的记录,可以这样定义Linq查询语句

var test1 = from p db.ProductLines where p.LineCode =='A' select p;

生成sql语句是这样的

注意到Where语句了吗?是WHERE UNICODE([t0].[LineCode]) = 65,这里先取LineCode列内容的UNICODE再和'A'的UNICODE比较。我们知道'A'和'a'的UNICODE是不同的。UNICODE('A') =65,UNICODE('a')=97,也就是说,我们在Linq to sql中这二个查询的结果是不一样的。

Linq 语句
var test1 = from p db.ProductLines
where p.LineCode =='a'
select p;
var test1 = from p db.ProductLines where p.LineCode =='A' select p;
生成sql语句
[t0].[LineCode],[t0].[QueueCount] [dbo].[ProductLine] [t0] UNICODE([t0].[LineCode]) = @p0

明显,

在Linq to sql查询char(1)类型字段是区分大小写的

这还会导致一个比较严重的问题,我们知道在sql Server中,

任何在运算符左边的操作都会使sql采用全表扫描

。也就是说,Linq的这个查询

会引起全表扫描

,即使[LineCode]列上定义了聚合索引。而如果是where [linecode]='A',则可以使用索引。我们看下这二种情况时的查询执行计划对比。

image

图中可以看出,Linq to sql 生成sql语句是表扫描,而后者则是索引查找。

3.

对策

在DBML设计器中将LineCode改成string类型。

image

看一下改了之后的查询

var test1 = from p db.ProductLines
where p.LineCode == ""
select p;
[t0].[LineCode],[t0].[QueueCount] [dbo].[ProductLine] [t0] [t0].[LineCode] = @p0 sqlProvider(sql2000) Model: AttributedMetaModel Build: 3.5.21022.8
Linq sql

改为string后,生成sql不再用UNICODE函数了,

解决了区分大小写和引起全表扫描的问题

。但又引起一个新的问题,因为数据库中存储的数据长度是1,在Insert和Update时就要注意,LineCode不要输入过长的内容,否则会出错了。

原文链接:https://www.f2er.com/mssql/64493.html
char(1)全表扫描

猜你在找的MsSQL相关文章