各位帮我看看是啥疑难啊, SQL运用变量会降低效率么

TB1
--------------------------
AAA  nvarchar  10  PK
BBB  char      1
CCC  int        4

AAA      BBB        CCC
--------------------------
100001    A          11
100002    B          2
100003    A          32
.......

TB1表内大概有 500W 记录 ,问题如下:

SELECT * FROM TB1 WHERE AAA='1234567'

DECLARE @AAA NVARCHAR(50)
SET @AAA = '1234567'
SELECT * FROM TB1 WHERE AAA=@AAA

---------
以上两句SQL 在客户的数据库服务器上, 第一句很快, 第二句根本就查不出来 , 但在我的开发电脑上, 没有区别

后来在自己电脑上找了一个结构相似的表作测试
发现在第二种写法比第一种要慢几十倍, 后又把参数DECLARE @AAA NVARCHAR(50)  改为 DECLARE @AAA VARCHAR(50)
查询速度又一样快了

但是, 以为自己找到原因, 又找了另外一张结构相似的表测试,
发现两种写法一样快, 不论第二种用NVARCHAR还是VARCHAR

换了台电脑测试, 还是一样快, 那为什么有的机子上有区别, 有的机子上甚至不能查,
这到底是为什么呢, 是SQL没安装好, 没有定论前, 总不能跟客户说 "你们重装下SQL试试 " 这么不负责任的话吧

寻求高手解答

---

这个问题第1个回答：
用查询计划看看有什么不一样

---

这个问题第2个回答：
...关注了,没遇到过这种问题

---

这个问题第3个回答：
SELECT * FROM TB1 WHERE AAA='1234567'

DECLARE @AAA NVARCHAR(50)
SET @AAA = '1234567'
SELECT * FROM TB1 WHERE AAA=@AAA

第一种写法用了变量，数据多时速度会很慢

---

这个问题第4个回答：
第二种

---

这个问题第5个回答：
nvarchar 是可变长度 Unicode 数据的数据类型

varchar[(n)]

长度为 n 个字节的可变长度且非 Unicode 的字符数据。n 必须是一个介于 1 和 8,000 之间的数值。存储大小为输入数据的字节的实际长度，而不是 n 个字节。所输入的数据字符长度可以为零。

nvarchar类型的数据查询时需要转换,所以慢.

---

这个问题第6个回答：
那一样数据量的表, 为什么有的表慢有的表快呢

就算是慢了点, 会有1:50的速度这么明显么

如果真是这么明显的速度对比, 那谁还会用SQL变量来开发呢, 不都字符串++了

---

这个问题第7个回答：
用ctrl+L看看查询计划

---

这个问题第8个回答：

引用 7 楼 jinjazz 的回复:

用ctrl+L看看查询计划

在你客户的数据库服务器上，用Ctrl+L 看执行计划的区别.

---

这个问题第9个回答：
看了, TableScan 成本94%

看又解决不了问题, 知道就说, 别故作高深

---

这个问题第10个回答：
汗...

不知道你的执行计划怎么说?

AAA若是Clustered index,那 WHERE AAA='123456' 应该是clusterd index seek.

因为条件只有1个, 而且是用的"="，可以排除参数臭探的原因，采用变量的方式，WHERE AAA=@AAA,理论让说生成的执行计划也是应是clustered index seek啊。

所以让你把两句SQL的执行计划帖出来啊，看哪里会有不同。

---

这个问题第11个回答：
可能有这样几种情况:
1.数据库在第一次执行的时候速度是明显要慢于后面的执行,查看你是不是正好第一次执行的是带参数的
2.nvarchar数据类型,需要到系统表中去查询一次,因此查询成本会略高于varchar,但应该只是在执行查询之前会出现转换

我用20w条记录做了测试[结果记录1w条],好像没有什么差别,
select  * from mis_so_dtl where substring(mnfctr,1,5)='53112'
cpu:297   reads:3843 duration:1406

declare @aa nvarchar(10)
set @aa='53112'
select * from mis_so_dtl where substring(mnfctr,1,5)=@aa
313 3869 1563
declare @aa varchar(10)
set @aa='53112'
select * from mis_so_dtl where substring(mnfctr,1,5)=@aa
266 3869 1560

---

这个问题第12个回答：


还有我发现在不同的机子上结果也有不同, 比方我的客户机子上, 第二种就根本解决不了

---

这个问题第13个回答：
up

---

这个问题第14个回答：
sql的 版本是一样的吗?还有语言类型什么的?

---

这个问题第15个回答：
@_@

sy_test表的SN字段，它的类型是VARCHAR 还是NVARCHAR ?

---

这个问题第16个回答：

看了１２楼的执行计划，我也晕了.
居然有一个会是index scan...

这样，一步一步的找原因吧.

SQL code

/*后来在自己电脑上找了一个结构相似的表作测试

发现在第二种写法比第一种要慢几十倍, 后又把参数DECLARE @AAA NVARCHAR(50)  改为 DECLARE @AAA VARCHAR(50)

查询速度又一样快了 

>>>>

在你的电脑上清除执行计划的cache.然后再试慢的那个,看它生成什么样的执行计划.



*/



DBCC FREEPROCCACHE

GO 

DBCC DROPCLEANBUFFERS

GO

--SET SHOWPLAN_ALL ON  --查看执行计划.

DECLARE @SN NVARCHAR(10)

SET @SN='111111111'



SELECT * FROM sy_test WHERE SN=@SN  --先试这个 



SELECT * FROM sy_test WHERE SN=CAST(@SN AS VARCHAR(20)) --再看这个的执行速度.

---

这个问题第17个回答：
SN字段是 varchar 50

SELECT * FROM sy_test WHERE SN=@SN  --耗时 1分40秒
SELECT * FROM sy_test WHERE SN=CAST(@SN AS VARCHAR(20)) --耗时 00秒

是变量与数据库中的类型不一至造成的么

---

这个问题第18个回答：
哎哟...我知道了。

是类型不一侄造成的.

类型不一侄时，VARCHAR 必需转成 NVARCHAR，然后再做匹配。

SQL code

[1] [2] 下一页