trim()默认仅去除ascii空格（u+0020），对制表符（\t）、换行符（\n）、回车符（\r）及全角空格（u+3000）完全无效，故常“清不干净”；需显式嵌套trim或改用regexp_replace等方案。
TRIM() 默认只去 ASCII 空格（U+0020），对制表符、换行符、全角空格完全无效；直接写 TRIM(col) 看似省事，但生产环境里大概率漏掉真实脏数据。
为什么 TRIM(col) 经常“没清干净”
前端粘贴、Excel 导入、日志拼接产生的字段，首尾常混有 \t（制表符）、\n（换行）、\r（回车）甚至 （全角空格 U+3000）。而 TRIM(col) 在所有主流 MySQL 版本中都只认 ASCII 空格——它根本“看不见”这些字符。
- 执行
SELECT TRIM(' \t\nhello\r\n ')，结果仍是' \t\nhello\r\n '（开头的\t\n和结尾的\r\n都还在） - 用
HEX(col)查看十六进制值：09=\t，0A=\n，0D=\r，3000= 全角空格 - MySQL 8.0+ 支持
[[:space:]]正则类，但TRIM()本身不支持该语法，必须显式列出字符
怎么安全去掉所有常见首尾空白字符
MySQL 不允许在 TRIM(BOTH ... FROM ...) 中传入多字符字符串（如 '\t\n\r'）作为 remstr，它会把整个字符串当做一个待匹配的子串，而非字符集合。所以不能偷懒写成 TRIM(BOTH '\t\n\r' FROM col)——这会报错或无效。
- 正确做法是逐层嵌套（兼容性好，5.7+ 都可用）：
TRIM(BOTH '\t' FROM TRIM(BOTH '\n' FROM TRIM(BOTH '\r' FROM col))) - 更清晰的替代方案（MySQL 8.0+）：
REGEXP_REPLACE(col, '^[[:space:]]+|[[:space:]]+$', '')，其中[[:space:]]覆盖\s所有 Unicode 空白类 - 如果还要处理全角空格，得额外加一层：
REPLACE(..., 0x3000, '')（需用十六进制字面量）
UPDATE 时最容易踩的三个坑
批量清洗不是写条 UPDATE ... SET col = TRIM(col) 就完事。真正出问题的环节都在 WHERE 条件和字段类型上。
- 漏
WHERE：整表更新可能触发外键约束失败、唯一索引冲突，或让CHAR类型字段因隐式截断产生意外行为 - 对
CHAR(n)字段用TRIM()是徒劳的——MySQL 存储时自动右补空格，读取时又自动截掉，TRIM()前后值看起来一样，实际没变 -
WHERE TRIM(col) = 'xxx'会让索引失效；应改用清洗后查询，或用WHERE col LIKE 'xxx%' AND LENGTH(TRIM(col)) = LENGTH('xxx')辅助（仍不完美）
上线前必须验证的两件事
别只信文档，要亲眼确认数据反应。尤其是从旧系统迁移或首次清洗时，TRIM() 的“安静”反而最危险——它不会报错，但可能把 ''（空字符串）和 ' '（单空格）都变成 ''，而业务逻辑可能依赖这两者的区别。
- 先抽样查真实脏数据：
SELECT id, col, HEX(col), LENGTH(col), LENGTH(TRIM(col)) FROM t WHERE col REGEXP '^[[:space:]]|[[space:]]$' LIMIT 5; - 再试跑小批量（带事务）：
BEGIN; UPDATE t SET col = TRIM(col) WHERE id IN (1,2,3); SELECT ROW_COUNT(); ROLLBACK;
真正复杂的是混合空白 + 业务语义判断。比如用户昵称字段含 '\nAlice'，TRIM() 后是 'Alice'，但若历史逻辑把换行当作分隔符，这一“清理”就破坏了数据结构。清洗前，得先搞清空格/换行在业务里是不是有意为之。
