SQL Server跨排序规则比较报错的直接解决方法是显式使用COLLATE关键字统一右侧操作数的排序规则，如WHERE name = @input COLLATE Latin1_General_100_CI_AS_SC_UTF8；需确保COLLATE与N前缀配合用于动态SQL，且避免因collation不匹配导致索引失效。
SQL Server 存储过程中跨排序规则比较报错：无法解决 equal to 操作的排序规则冲突
直接用 = 比较两个不同 collation 的字符串字段，SQL Server 会拒绝执行并抛出错误：Cannot resolve collation conflict。这不是语法错，是类型系统在阻止隐式转换带来的语义风险。
常见触发场景：
- 数据库默认
collation是SQL_Latin1_General_CP1_CI_AS，但某列显式设为Latin1_General_100_CI_AS_SC_UTF8 - 临时表字段继承了会话默认规则，而主表字段用了不同规则
- 动态 SQL 中拼接的字面量（如
'张三'）按数据库默认规则解析，与 NVARCHAR 参数实际 collation 不一致
最稳妥的做法是显式用 COLLATE 统一右侧操作数的规则：
SELECT * FROM users WHERE name = @input COLLATE Latin1_General_100_CI_AS_SC_UTF8;
注意：COLLATE 必须加在表达式右侧（即被比较值上），不能只加在变量或参数名后；它不改变变量本身，只临时覆盖该次比较的规则。
存储过程里 WHERE 条件用 COLLATE 后索引失效？
加了 COLLATE 不一定让索引失效，关键看是否“匹配索引列定义时的 collation”。
如果索引建在 name 列上，而该列定义时就是 NVARCHAR(50) COLLATE Latin1_General_100_CI_AS_SC_UTF8，那么下面这句仍能走索引：
WHERE name = @input COLLATE Latin1_General_100_CI_AS_SC_UTF8
但如果列是 SQL_Latin1_General_CP1_CI_AS，你强制用 Latin1_General_100_CI_AS_SC_UTF8 去比，SQL Server 就得先转码再查——此时索引大概率跳过，执行计划里会出现 CONVERT_IMPLICIT 警告。
验证方法：
- 查执行计划，看
Seek Predicate是否变成Residual Predicate - 用
DBCC SHOW_STATISTICS确认统计信息是否基于当前 collation 生效
动态 SQL 中 COLLATE 容易漏掉 N 前缀和显式规则
动态拼接字符串时，COLLATE 和 N 前缀必须同时存在，缺一不可。
错误写法（两个坑）：
SET @sql = 'SELECT * FROM t WHERE name = ''' + @input + ''' COLLATE Latin1_General_100_CI_AS_SC_UTF8';
问题：
-
@input是 NVARCHAR，但拼进字符串字面量后，整个''' + @input + '''被当成了 VARCHAR 字面量（没N前缀） -
COLLATE加在字符串末尾，但前面已按非 Unicode 规则解析过一次，乱码早已发生
正确写法：
SET @sql = N'SELECT * FROM t WHERE name = N''' + REPLACE(@input, '''', '''''') + N''' COLLATE Latin1_General_100_CI_AS_SC_UTF8';
重点：N''...'' 包裹整个字面量，REPLACE 防单引号注入，COLLATE 紧贴字面量右端。
函数参数传入时 collation 丢失怎么办
存储过程参数声明为 @p NVARCHAR(100)，不代表它自带 collation；它的 collation 来自调用上下文——比如客户端连接字符串里指定的 database，或 EXEC 所在批处理的默认库。
这意味着同一段存储过程，在不同数据库上下文中执行，@p 的隐式 collation 可能不同，导致比较结果不一致。
安全做法是：在过程开头就显式 cast + collate 参数：
DECLARE @p_fixed NVARCHAR(100) = CAST(@p AS NVARCHAR(100)) COLLATE Latin1_General_100_CI_AS_SC_UTF8;
后续所有比较、拼接、函数调用（如 CHARINDEX, REPLACE）都基于这个固定规则的变量，避免中间环节被悄悄转换。
真正麻烦的是跨库查询或链接服务器场景——那里 collation 优先级更复杂，COLLATE 得加在每一处涉及字符串操作的位置，不能只靠一次 cast。
