Azure SQL Server中varchar列与'x'和N'x'比较的性能差异排查

问题背景 #

我们有一条带简单WHERE子句的SQL语句：

no_identificador_rubro.cod_identificador_rubro = 'SRISueldos'

该列数据类型是varchar(10)，按理论应该和非Unicode值比较，但实际执行性能极差。

反常的是，用“错误”方式——给字符串加N前缀（Unicode值）和varchar列比较时，性能直接提升了10倍：

no_identificador_rubro.cod_identificador_rubro = N'SRISueldos'

两种写法的执行计划完全不同，这是为什么？

我们使用的是Azure上的SQL Server，排序规则为modern_spanish_ci_as，配置10个DTU。

完整SQL语句 #

SELECT 
    no_rol_persona.cod_persona
FROM
    no_rol_cabecera
JOIN 
    no_rol_persona ON no_rol_cabecera.cod_rol_cabecera = no_rol_persona.cod_rol_cabecera
JOIN
    no_rol_rubro ON no_rol_persona.cod_rol_persona = no_rol_rubro.cod_rol_persona
JOIN 
    no_rol_detalle ON no_rol_rubro.cod_rol_rubro = no_rol_detalle.cod_rol_rubro
JOIN 
    no_rubro ON no_rol_rubro.cod_rubro = no_rubro.cod_rubro
JOIN 
    si_sucursal ON no_rol_cabecera.cod_sucursal = si_sucursal.cod_sucursal
JOIN  
    si_empresa ON si_sucursal.cod_empresa = si_empresa.cod_empresa
JOIN
    no_tipo_rol ON no_rol_cabecera.cod_tipo_rol = no_tipo_rol.cod_tipo_rol
JOIN
    no_plantilla_identificador ON no_rubro.cod_plantilla_detalle = no_plantilla_identificador.cod_plantilla_detalle
JOIN 
    no_identificador_rubro ON no_plantilla_identificador.cod_identificador_rubro = no_identificador_rubro.cod_identificador_rubro
WHERE
    si_empresa.cod_empresa = '01' 
    AND no_tipo_rol.cod_tipo_rol IN ('QT005', 'QT003', 'QT001', 'QT002')
    AND no_rol_cabecera.fecha_inicial_rol >= @FechaIni 
    AND no_rol_cabecera.fecha_inicial_rol <= @FechaFin 
    AND no_identificador_rubro.cod_identificador_rubro = 'SRISueldos'  -- <- 关键差异点
    AND no_rol_detalle.valor_rol_detalle <> 0
GROUP BY 
    no_rol_persona.cod_persona

测试结果汇总 #

• 非Unicode值写法：执行速度极慢，执行计划低效
• N前缀Unicode值写法：速度提升10倍，执行计划更优
• 后续补充测试：
  • 加OPTION(MAXDOP 1)：耗时4分钟
  • 加OPTION(RECOMPILE)：耗时7分钟（反而更慢）
  • 再次用N'SRISueldos'：仅耗时6秒

原因解析 #

核心是隐式数据类型转换+统计信息/参数嗅探偏差导致的执行计划选择差异：

1. 非Unicode比较的执行计划误区
   按道理varchar列和varchar常量比较应该能用上索引，但如果该列的统计信息过期、数据分布倾斜（比如大部分值都是某个特定内容），优化器会错误估算匹配行数，进而选择低效的执行计划——比如放弃索引全表扫描、用哈希连接替代嵌套循环等。

2. Unicode比较的“意外反转”
   当varchar列和nvarchar常量比较时，SQL Server会把varchar列隐式转换为nvarchar（Unicode优先级更高），这看起来会导致索引失效，但此时优化器可能基于不同的统计信息逻辑估算行数，或者触发了不同的计划生成规则——反而选到了更高效的索引查找、调整了表连接顺序，最终得到了优计划。

3. 参数嗅探的推波助澜
   语句中用到了@FechaIni和@FechaFin变量，可能存在参数嗅探问题：OPTION(RECOMPILE)更慢，说明重新编译时优化器用当前参数生成的计划更差；而N'xxx'的写法刚好绕过了原有错误的统计信息估算，让优化器选到了更适配的执行计划。

4. 排序规则的潜在影响
   modern_spanish_ci_as排序规则下，Unicode和非Unicode字符串的比较逻辑存在细微差异，这也可能影响优化器对数据分布的判断，进而改变执行计划的选择。

解决建议 #

• 更新统计信息：执行UPDATE STATISTICS no_identificador_rubro，给优化器准确的数据分布依据
• 检查索引有效性：确认no_identificador_rubro.cod_identificador_rubro上的索引存在且未失效
• 优化参数化查询：可以用OPTION(OPTIMIZE FOR (@FechaIni = '指定日期', @FechaFin = '指定日期'))，让优化器基于更贴合业务的参数生成计划
• 避免依赖隐式转换：如果要稳定用高效计划，可显式调整数据类型匹配，或结合执行计划强制指定索引

内容的提问来源于stack exchange，提问作者Theo