MS SQL = or like?# Database - 数据库
c*t
1 楼
MS SQL:
where field = 'string'
or
where field like 'string'?
Both work, which one is right?
where field = 'string'
or
where field like 'string'?
Both work, which one is right?
c*t
2 楼
It seems "=" is faster. :-)
【在 c**t 的大作中提到】
: MS SQL:
: where field = 'string'
: or
: where field like 'string'?
: Both work, which one is right?
【在 c**t 的大作中提到】
: MS SQL:
: where field = 'string'
: or
: where field like 'string'?
: Both work, which one is right?
f*g
3 楼
if u know the exact string you're looking ofr, why bother to use LIKE?
【在 c**t 的大作中提到】
: It seems "=" is faster. :-)
【在 c**t 的大作中提到】
: It seems "=" is faster. :-)
c*t
4 楼
One said LIKE is standard;
【在 f*****g 的大作中提到】
: if u know the exact string you're looking ofr, why bother to use LIKE?
【在 f*****g 的大作中提到】
: if u know the exact string you're looking ofr, why bother to use LIKE?
n*a
5 楼
It matters not which one performs better or which one is standard.
The only thing that matters is correctness.
If the question you query is trying to answer requires LIKE,
by all means, use LIKE, and forget about the performance.
Performance will only come to play when = or like will provide
the SAME CORRECT answer.
As fryking mentioned, if you know the exact string, use =.
LIKE will be the wrong answer.
It seems unlikely to me where = or like will be equivalent
and provide the same correct answ
【在 c**t 的大作中提到】
: One said LIKE is standard;
The only thing that matters is correctness.
If the question you query is trying to answer requires LIKE,
by all means, use LIKE, and forget about the performance.
Performance will only come to play when = or like will provide
the SAME CORRECT answer.
As fryking mentioned, if you know the exact string, use =.
LIKE will be the wrong answer.
It seems unlikely to me where = or like will be equivalent
and provide the same correct answ
【在 c**t 的大作中提到】
: One said LIKE is standard;
c*t
6 楼
1) select * from TBL
where email = 'w*****[email protected]'
2) select * from TBL
where like 'w*****[email protected]'
Time: 1) 00:00:01 2) 00:00:04
My observation is = faster for this case.
【在 n********a 的大作中提到】
: It matters not which one performs better or which one is standard.
: The only thing that matters is correctness.
: If the question you query is trying to answer requires LIKE,
: by all means, use LIKE, and forget about the performance.
: Performance will only come to play when = or like will provide
: the SAME CORRECT answer.
: As fryking mentioned, if you know the exact string, use =.
: LIKE will be the wrong answer.
: It seems unlikely to me where = or like will be equivalent
: and provide the same correct answ
where email = 'w*****[email protected]'
2) select * from TBL
where like 'w*****[email protected]'
Time: 1) 00:00:01 2) 00:00:04
My observation is = faster for this case.
【在 n********a 的大作中提到】
: It matters not which one performs better or which one is standard.
: The only thing that matters is correctness.
: If the question you query is trying to answer requires LIKE,
: by all means, use LIKE, and forget about the performance.
: Performance will only come to play when = or like will provide
: the SAME CORRECT answer.
: As fryking mentioned, if you know the exact string, use =.
: LIKE will be the wrong answer.
: It seems unlikely to me where = or like will be equivalent
: and provide the same correct answ
a*t
7 楼
=
use like for '%string%' search
【在 c**t 的大作中提到】
: MS SQL:
: where field = 'string'
: or
: where field like 'string'?
: Both work, which one is right?
use like for '%string%' search
【在 c**t 的大作中提到】
: MS SQL:
: where field = 'string'
: or
: where field like 'string'?
: Both work, which one is right?
s*s
8 楼
To make your comparison meaningful, you need to give the table structure and
the index(es) on it.
I agree that generally = is more efficient than like since like uses range
scan while = is exact match.
【在 c**t 的大作中提到】
: 1) select * from TBL
: where email = 'w*****[email protected]'
: 2) select * from TBL
: where like 'w*****[email protected]'
: Time: 1) 00:00:01 2) 00:00:04
: My observation is = faster for this case.
the index(es) on it.
I agree that generally = is more efficient than like since like uses range
scan while = is exact match.
【在 c**t 的大作中提到】
: 1) select * from TBL
: where email = 'w*****[email protected]'
: 2) select * from TBL
: where like 'w*****[email protected]'
: Time: 1) 00:00:01 2) 00:00:04
: My observation is = faster for this case.
c*t
9 楼
The TBL is a general one, no index(es) built on it. If the compiler is smart
enought, will it convert "email like '[email protected]'" to "email = '[email protected]'"?
For the time I gave which is meaningless without knowing the table strtucture
and index(es), you are damn right. :-) But I just tried to show the difference
【在 s******s 的大作中提到】
: To make your comparison meaningful, you need to give the table structure and
: the index(es) on it.
: I agree that generally = is more efficient than like since like uses range
: scan while = is exact match.
enought, will it convert "email like '[email protected]'" to "email = '[email protected]'"?
For the time I gave which is meaningless without knowing the table strtucture
and index(es), you are damn right. :-) But I just tried to show the difference
【在 s******s 的大作中提到】
: To make your comparison meaningful, you need to give the table structure and
: the index(es) on it.
: I agree that generally = is more efficient than like since like uses range
: scan while = is exact match.
相关阅读
请问一个问题1Problem with this T-SQL statementquestion on large tables (>=800 million records, 10 G bytes of data)excel的数据如何导入到access/mssql？有没有database system concept 5th edition的电子版下载？Worldwide RDBMS 2006 Vendor Shares: Preliminary Results for the Top 5 Vendors(LINK)Oralce把数据存在哪个目录下的？OpenOffice.org Base sloooooowwwMySQL going pulic?(ZZ)请推荐一本SQL Server的书Seems Oracle 11g is cominghow to make query faster?请教sql server DB 大侠Any Oracle book for SQL server developer? MySQL Falcon Storage Engine Open Sourced(ZZ)SQL Server 2005 Enforce password policy请教把access编码由unicode换成ascii的方法[合集] 做DBA需要什么文凭?问个database design的问题如何让Office / Access ignore system locale?