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