SQL Server中WHERE子句用=替代LIKE的优势及性能对比：date LIKE '%YYYY%' vs YEAR(Date)='YYYY'

普遍场景下=和LIKE的性能差异 #

• 索引利用能力：=运算符属于等值匹配，只要列上建有合适索引，SQL Server能直接命中索引快速定位数据；而LIKE如果是'%xxx'或'%xxx%'这种通配符开头/前后模糊的写法，完全无法利用索引，只能走全表扫描，数据量大时性能差距极大。哪怕是'xxx%'前缀匹配，虽可能用到索引，但执行计划稳定性也不如等值匹配。
• 隐式转换开销：=会严格校验数据类型，避免不必要的类型转换；但LIKE用于非字符串类型（比如日期、数字）时，会触发隐式转换，把列值转成字符串再匹配，额外增加CPU开销，还会导致索引失效。
• 执行计划效率：等值匹配的执行计划逻辑简单，优化器能精准估算返回行数，选择最优执行路径；而模糊匹配的行数估算误差大，容易生成低效的执行计划。

针对date LIKE '%YYYY%'与YEAR(Date) = 'YYYY'的具体对比 #

这两个写法都属于非sargable表达式（无法利用索引），但性能仍有明显差距：

1. date LIKE '%YYYY%'的问题 #

• 强制把日期类型转成字符串，逐行做模糊匹配，CPU和IO开销都很大。日期列存储的是二进制格式的日期值，转成字符串本身需要计算，再加上%YYYY%的模糊匹配要扫描每个字符串的所有字符，效率极低。
• 还可能出现逻辑错误：比如日期字符串格式不是YYYY-MM-DD（如部分数据是MM/DD/YYYY），或存在异常日期值时，会出现误匹配。

2. YEAR(Date) = 'YYYY'的优势 #

• 直接对日期类型计算年份，不需要转成字符串，计算开销远小于字符串模糊匹配。SQL Server对日期类型的年份提取是原生轻量操作，比字符串匹配快很多。
• 逻辑更严谨：不会因为日期格式变化出现误匹配，只要是该年份的日期都会被正确筛选。

最优替代方案 #

不管是上面哪种写法，都不如范围查询性能好：

date >= '20230101' AND date < '20240101'

这个写法是sargable的，能完美利用日期列上的索引，直接定位到指定年份的所有数据，性能是三者里最优的。

总结 #

• 当逻辑上可用=替代LIKE时，性能优势非常明显，核心是能利用索引、避免隐式转换。
• 但像YEAR(Date) = 'YYYY'这种用了=但带函数的情况，仍无法利用索引，不过依然比通配符开头的LIKE写法高效。
• 处理日期筛选时，优先用范围查询，别依赖函数或模糊匹配。

内容的提问来源于stack exchange，提问作者Ferhat Lyes FERHAT