TRIM仅能删除字符串首尾连续匹配的字符，无法处理中间空格或复杂包围符；真正批量清洗需用REGEXP_REPLACE，但各数据库语法差异大，应分层处理、注意NULL和性能。
TRIM 只能去首尾，别指望它删中间空格或特殊符号
很多人一看到字符串清洗就先写 TRIM()，结果发现 TRIM(' hello world ') 能变 'hello world'，但中间三个空格还在；更别说遇到 '
hello
' 或 '[ERROR]user@domain.com[END]' 这类带包围符的，TRIM() 直接失效。
根本原因：SQL 标准里的 TRIM()（包括 MySQL/PostgreSQL 的扩展形式）只作用于字符串**首尾连续匹配的字符集**，不支持模式、不扫描内部、也不支持正则逻辑。
- MySQL 支持
TRIM(BOTH FROM col)和自定义字符集，如TRIM(BOTH '[' FROM col)，但仅限单字符或显式列出的字符（TRIM(BOTH '[]' FROM col)表示删首尾的[或]） - PostgreSQL 的
TRIM()不支持字符集列表，只能单字符；想删多个不同首尾符得嵌套调用，难维护 - SQLite 的
TRIM()最简陋，连BOTH/LEADING/TRAILING都不支持，纯靠TRIM(col, 'x')
REGEXP_REPLACE 是批量清洗的核心，但各数据库语法差异大
真正能批量修整字符串的，是 REGEXP_REPLACE() —— 它允许你用正则一次定位并替换任意位置的内容。但注意：不是所有 SQL 引擎都原生支持，且函数名、参数顺序、标志位写法全都不一样。
常见场景与写法对比：
- MySQL 8.0+：
REGEXP_REPLACE(col, '\s+', ' ')把连续空白（含 ）缩成单空格；注意双反斜杠转义，标志位用第4个参数，如REGEXP_REPLACE(col, '^\s+|\s+$', '', 'g') - PostgreSQL：
REGEXP_REPLACE(col, 's+', ' ', 'g')，单反斜杠即可，标志位是字符串'g'（全局）、'i'（忽略大小写），且默认只换第一次，必须显式加'g' - SQLite（需加载 regexp 扩展）：
REGEXP_REPLACE(col, '[[:space:]]+', ' ')，不支持s简写，得用 POSIX 字符类；无内置REGEXP_REPLACE，得自己编译或用扩展 - BigQuery：
REGEXP_REPLACE(col, r's+', ' ')，用r''原始字符串避免转义混乱，标志位写在正则里，如r'(?i)foo'
一个实用组合：先用 REGEXP_REPLACE() 清理首尾干扰符 + 中间冗余空白，再用 TRIM() 做最终兜底（比如某些数据库对 Unicode 空格支持不一致，TRIM() 更稳）。
真实清洗链路建议：分层处理，别堆在一个 REGEXP_REPLACE 里
试图用一条超长正则搞定所有脏数据（比如邮箱字段里混着 ' [user@domain.com] '、'user@domain.com (valid)'、'U$ER@DOMAIN.COM'），最后要么漏匹配，要么误伤，还难调试。
推荐分三步走，每步专注一类问题：
-
第一步：剥离固定包围符 —— 如
REGEXP_REPLACE(col, '^\[.*?\]|\[.*?\]$', '')（MySQL）删首尾中括号及内容；PostgreSQL 用REGEXP_REPLACE(col, '^[.*?]|[.*?]$', '') -
第二步：标准化空白与控制符 ——
REGEXP_REPLACE(col, '[[:space:] - - ]+', ' ')（POSIX 兼容写法，覆盖大多数不可见 ASCII 控制符） -
第三步：业务规则修正 —— 如邮箱小写化：
LOWER(col)；或替换非法字符：REGEXP_REPLACE(col, '[^a-zA-Z0-9@._-]', '')（注意别过度清洗，@._- 是邮箱合法字符）
顺序不能乱：先去包围符，再压空白，最后做业务转换。否则像 ' [user@domain.com] '，如果先压空白，会变成 '[user@domain.com]'，中括号就进到中间去了，后续更难剥离。
性能和 NULL 处理容易被忽略
批量清洗最常踩的坑不是语法，而是没考虑 NULL 和性能爆炸。
-
REGEXP_REPLACE(NULL, ...)在多数数据库返回NULL，但如果你的清洗逻辑依赖非空结果（比如后续LENGTH()判断），得提前COALESCE(col, '')或加WHERE col IS NOT NULL - 正则越复杂，CPU 消耗越高。在千万级表上执行
REGEXP_REPLACE(col, '\s+', ' ', 'g')可能比REPLACE(REPLACE(col, ' ', ' '), ' ', ' ')慢 5–10 倍。简单替换优先用REPLACE()，正则留作兜底 - MySQL 对
REGEXP_REPLACE()不走索引，PostgreSQL 的~操作符也基本无法利用 btree 索引——清洗操作尽量放在 ETL 或应用层，别在高频查询里实时算
真正要跑批量清洗任务时，先在小样本（LIMIT 100）验证正则逻辑，再加 EXPLAIN 看执行计划，尤其注意是否触发全表扫描或临时表。正则不是银弹，它只是工具箱里最锋利、也最容易割手的那一把。
