SQL中查不到的“空格”常为u00A0、 等不可见字符，需用HEX()/DUMP()诊断，MySQL用嵌套REPLACE()或REGEXP_REPLACE()清洗，PostgreSQL推荐translate()或REGEXP_REPLACE()。
SQL里查不到的空格，很可能是u00A0或 这类不可见字符
肉眼看着是“正常字符串”，WHERE name = '张三'却查不到——大概率是数据里混入了全角空格、不间断空格u00A0、制表符 、零宽空格u200B等。这些字符在SELECT中常被UI截断或渲染为“空白”，但数据库严格区分字节值，匹配必然失败。
实操建议：
- 先用
HEX()或ENCODE()（PostgreSQL）看原始字节：SELECT HEX(name) FROM users WHERE id = 123，比对末尾是否多出A0（u00A0）或09（ - MySQL用
DUMP()更直观：SELECT DUMP(name) FROM users WHERE id = 123，直接显示ASCII/Unicode码点 - 别依赖
TRIM()——它默认只处理空格0x20，对u00A0完全无效
MySQL中用REPLACE()批量清理常见隐藏字符
REPLACE()是最快上手的清洗方式，但必须链式调用，因为一次只能替换一种字符。注意：嵌套过深会影响可读性，5层以内较安全。
常见组合示例（MySQL）：
SELECT REPLACE(
REPLACE(
REPLACE(name, 'u00A0', ' '), -- 全角空格→半角
' ', ' '),
'
', ' ')
FROM users
WHERE name LIKE '%张三%';关键细节：
- MySQL 5.7+ 支持Unicode转义，但需确保连接字符集为
utf8mb4，否则u00A0可能被截断 - 用单引号包裹转义序列，双引号在某些配置下会失效
- 生产环境慎用
UPDATE直接改，先用SELECT验证效果，再加LIMIT分批执行
PostgreSQL用translate()一次性替换多字符更高效
比起MySQL的嵌套REPLACE()，PostgreSQL的translate()函数能用一次调用替换多个字符，性能更好，写法也更紧凑。
语法：translate(string, from_chars, to_chars)，长度必须一致。
实操示例：
SELECT translate(name, E'u00A0 ', ' ') FROM users WHERE position(E'u00A0' in name) > 0;
注意事项：
-
E''前缀必须加，否则u00A0会被当作普通字符串而非Unicode转义 - 目标字符
to_chars若短于from_chars，多余字符会被删掉（不是报错），容易误删内容 - 无法处理变长字符如零宽空格
u200B，需配合regexp_replace()
用正则REGEXP_REPLACE()处理复杂隐藏字符模式
当需要匹配“连续多个空白类字符”或“行首行尾任意空白”，正则才是可靠解法。但性能开销明显高于REPLACE或translate，只在必要时用。
MySQL 8.0+ 和 PostgreSQL 都支持，但语法不同：
- MySQL：
REGEXP_REPLACE(name, '[[:space:]]+', ' ')—— 匹配所有空白字符并压缩为单空格 - PostgreSQL：
REGEXP_REPLACE(name, E'[\s\u00A0\u200B]+', ' ', 'g')——\s不含u00A0，必须显式补充 - Oracle用户注意：
REGEXP_REPLACE不支持u语法，得用UNISTR('...')构造Unicode字符
最容易被忽略的一点：正则默认是逐行匹配，如果字段含换行符且想全局替换，MySQL要加'g'标志，PostgreSQL需明确写'g'参数，否则只换第一个匹配项。
