REPLACE函数执行字面量逐次替换，三个参数缺一不可，且NULL直接透传、大小写敏感、不支持正则；常见陷阱包括NULL传播、排序规则导致匹配失败、长文本截断及WHERE中使用引发全表扫描。
直接用
函数就行，但得注意它不处理大小写、不支持正则、NULL 会直接透传——很多“没替换成功”其实是因为字段本身是
或者大小写不匹配。
REPLACE 基本用法和 NULL 陷阱
只做字面量逐次替换，三个参数缺一不可：
。最常踩的坑是忽略
传播规则：
结果仍是
，不是空字符串
如果目标列允许为
，又没加
或
，SELECT 或 UPDATE 后会出现意外的
值
在
语句中盲目执行，比如
，一旦 nickname 有
，那条记录的 nickname 就被设成
了
大小写敏感导致替换失效
SQL Server 默认使用数据库或列的排序规则（collation）做比较，多数情况下不区分大小写，但如果你显式用了
或连接了区分大小写的数据库，
就完全不会生效：
查当前列排序规则：
临时强制不区分大小写：
但别滥用
，它会让索引失效；更稳妥的做法是在应用层统一转小写，或建计算列
长度截断和性能隐患
返回类型取决于输入：只要有一个参数是
，结果就是
；否则是
。但关键限制是：
如果
不是
或
，返回值会被硬截断到 8000 字节（约 4000 个中文字符）
想安全处理长文本，必须显式转换：
千万别在
子句里写
——这会导致全表扫描，索引完全失效
多层替换和嵌套顺序
要同时处理换行符、多余空格、特殊符号等，得靠嵌套
，但顺序决定结果：
先删
再压空格：
；反过来就可能留下首尾双空格
连续替换同一类字符（如全角→半角），建议用
（SQL Server 2017+）更高效，例如：
嵌套超过 3 层就该考虑是否该抽到应用层，或者改用
（SQL Server 2025+ / Azure SQL 托管实例）
真正麻烦的不是语法写不对，而是没意识到
是纯字符串机械匹配——它不知道“前缀”“后缀”“单词边界”，也从不重叠匹配；想干这些事，要么提前清洗数据结构，要么升级到正则支持环境。
REPLACENULLREPLACEREPLACE(string_expression, string_pattern, string_replacement)NULLREPLACE(NULL, 'a', 'b')NULLNULLWHERE col IS NOT NULLCOALESCE(col, '')NULLUPDATEUPDATE users SET nickname = REPLACE(nickname, 'old', 'new')NULLNULLCOLLATE SQL_Latin1_General_CP1_CS_ASREPLACE('ABC', 'abc', 'x')SELECT collation_name FROM sys.columns WHERE object_id = OBJECT_ID('users') AND name = 'nickname'REPLACE(nickname COLLATE SQL_Latin1_General_CP1_CI_AS, 'OLD', 'new')COLLATEREPLACEnvarcharnvarcharvarcharstring_expressionvarchar(max)nvarchar(max)REPLACE(CAST(long_text AS nvarchar(max)), 'x', 'y')WHEREWHERE REPLACE(title, 'temp', '') = 'final'REPLACE\r\nREPLACE(REPLACE(text, '\r\n', ' '), ' ', ' ')TRANSLATETRANSLATE(col, N' ，。！？；：""''（）', N' ,.!?;:"\'\'()')REGEXP_REPLACEREPLACE