SQL Server中换行符主要有两种组合：回车CHAR(13)（CR）和换行CHAR(10)（LF），Windows下通常为CHAR(13)+CHAR(10)，而Linux或Excel导入数据可能仅含CHAR(10)。
SQL Server里换行符到底有几种？
SQL Server中常见的换行符不是一种，而是两种组合：回车 CHAR(13)（CR）和换行 CHAR(10)（LF）。Windows系统下通常以 CHAR(13) + CHAR(10) 形式出现，也就是 CHAR(13)+CHAR(10)，而某些导入场景（比如从Linux或Excel复制过来的数据）可能只含 CHAR(10)。直接只替换 CHAR(13) 往往清不干净。
常见错误现象：
– 用 REPLACE(col, CHAR(13), '') 后，字段在SSMS结果网格里仍显示为多行
– 导出到CSV后，某字段内容意外换行，破坏文件结构
– 应用层渲染时出现空白行或错位
REPLACE嵌套处理：一次干掉CR/LF组合
最稳妥的做法是先清除 CHAR(13)+CHAR(10) 组合，再单独清理残留的 CHAR(13) 或 CHAR(10)。顺序很重要——如果先删单个，组合就拆散了，反而漏处理。
- 推荐写法：
REPLACE(REPLACE(REPLACE(col, CHAR(13)+CHAR(10), ' '), CHAR(13), ' '), CHAR(10), ' ') - 把所有换行统一替换成空格（也可用
''，但空格更安全，避免相邻文字粘连） - 注意：
CHAR(13)+CHAR(10)是字符串拼接，不是加法运算，不能写成CHAR(13+10) - 若字段为
TEXT类型（已弃用但仍存在），需先CAST(col AS VARCHAR(MAX))再替换
WHERE条件里匹配含换行符的数据难在哪？
直接写 WHERE col LIKE '%'+CHAR(13)+'%' 大概率查不到——因为实际数据可能是 CHAR(13)+CHAR(10)，或者换行符前后夹着不可见空格。而且 LIKE 对 CHAR(13) 这类控制字符匹配不稳定。
实操建议：
- 先用
SELECT col, DATALENGTH(col), LEN(col) FROM tbl WHERE col LIKE '%abc%'辅助判断：若DATALENGTH明显大于LEN，大概率含不可见字符 - 用
PATINDEX('%' + CHAR(13) + '%', col) > 0比LIKE更准，但依然要覆盖CHAR(10) - 真正可靠的排查方式是：用
SELECT CAST(col AS VARBINARY(MAX))看原始字节，确认具体是哪几个字节（0x0D = CR，0x0A = LF）
UPDATE时性能与事务风险提醒
对大表执行 UPDATE ... SET col = REPLACE(...) 可能锁表、日志暴涨，尤其当字段是 VARCHAR(MAX) 或含大量数据时。
- 务必在非高峰时段操作，并提前备份或测试子集：
UPDATE TOP (1000) ... - 避免在没有
WHERE条件下全表更新——哪怕看起来“都该清理”，也先用PATINDEX定位真实脏数据 - 如果列上有索引且被频繁查询，替换后记得
UPDATE STATISTICS，否则执行计划可能劣化 - 应用层若缓存了原始值（如Redis里存了带换行的JSON），数据库改了，缓存未必同步
换行符看不见，但它的影响会从SSMS一路渗透到API响应头、CSV导出、甚至前端textarea渲染。动手前先 SELECT TOP 5 CAST(col AS VARBINARY(MAX)) 看一眼原始字节，比猜省半小时。
