SQL Server中查字段是否含换行符、回车符或制表符，应使用CHARINDEX函数：WHERE CHARINDEX(CHAR(10),col)>0查换行符，WHERE CHARINDEX(CHAR(13),col)>0查回车符，WHERE CHARINDEX(CHAR(9),col)>0查制表符；建议三者联合扫描以防遗漏。
查字段里有没有换行符或制表符
别猜，直接用 CHARINDEX 或 LIKE 扫一遍。SQL Server 里最稳的是：
-
WHERE CHARINDEX(CHAR(10), column_name) > 0—— 查换行符（LF） -
WHERE CHARINDEX(CHAR(13), column_name) > 0—— 查回车符（CR） -
WHERE CHARINDEX(CHAR(9), column_name) > 0—— 查制表符（TAB） - 如果要查 Windows 风格的
CHARINDEX(CHAR(13)+CHAR(10), column_name) > 0
注意：只查 CHAR(10) 可能漏掉 CHAR(13) 单独存在的记录（比如 Mac 老数据），建议三者都扫。
SELECT 时临时清除换行和制表符
嵌套 REPLACE 是跨库通用解法，但顺序和写法得对：
- SQL Server / Oracle：用
CHAR(13)、CHAR(10)、CHAR(9) - MySQL：可用
' '、' '、' '字面量，更直观 - PostgreSQL：推荐
E' '、E' '、E' '，否则反斜杠不生效
示例（SQL Server）：
SELECT REPLACE(REPLACE(REPLACE(column_name, CHAR(13), ''), CHAR(10), ''), CHAR(9), '') FROM table_name
性能提醒：这个表达式在 WHERE 里用会导致索引失效；仅用于展示清洗结果没问题，别拿它做条件过滤。
UPDATE 前必须加 WHERE 条件
直接 UPDATE SET col = REPLACE(...) 全表跑，风险很高：
- 没加
WHERE：干净字段也被“重写”，徒增日志和锁等待 - 没限定范围：大表 UPDATE 可能卡住业务，尤其在高峰期
- 清完可能留双空格：比如
REPLACE(col, ' ', ' ')
安全做法是先查出要处理的行：
SELECT id, column_name FROM table_name WHERE CHARINDEX(CHAR(10), column_name) > 0 OR CHARINDEX(CHAR(13), column_name) > 0 OR CHARINDEX(CHAR(9), column_name) > 0
确认无误后再执行带 WHERE 的 UPDATE。
真正难搞的是 Unicode 换行符
标准 REPLACE 对 U+2028（行分隔符）、U+2029（段落分隔符）完全无效。这类字符常见于网页爬虫、富文本编辑器导出内容。
如果你发现“已经清了
，但前端还是断行”，大概率是它们：
- SQL Server 不支持直接用
UNICODE()或NCHAR()匹配这些码位，得靠应用层处理 - PostgreSQL 可用
REGEXP_REPLACE(col, E'[\u2028\u2029]', '', 'g')（需开启icu扩展） - MySQL 8.0+ 支持
REGEXP_REPLACE(col, '[\u2028\u2029]', '')，但低版本只能靠程序读出来再清洗
别指望一条 SQL 解决所有换行问题——Unicode 控制符得单独识别、单独应对。
