MySQL REGEXP_REPLACE 怎样清理字段中的连续空格

只需把字段中的连续普通空格压成一个时，可用 REGEXP_REPLACE(display_name, ' {2,}', ' ')；如果还要去掉首尾普通空格，再包一层 TRIM()。两项规则要分开决定：压缩连续空格不会自动删除首尾的单个空格，也不等于清理所有空白字符。

官方文档地址：https://dev.mysql.com/doc/refman/8.4/en/regexp.html

本文使用 MySQL 8.4 的函数语义。我更倾向于先做一个保留原值的预览，再决定是否写回；下面把“导入名单的展示名清理”做成独立临时表小项目。它是供读者运行的示例，并非真实客户数据或已经执行的清理记录。

先确定哪些间距可以改

本项目只处理普通空格 U+0020，目标是把两个及以上连续普通空格变成一个。模式 ' {2,}' 中，单引号后的第一个字符就是普通空格，{2,} 表示重复至少两次。替换字符串 ' ' 中也有一个普通空格，不能误写成空字符串。

对于展示名，连续空格可能是导入噪声；对于排版文本、代码片段和格式化编号，空格可能有意义。我的选择是先明确字段用途，宁可保留不确定的字符，也不默认把所有空白都统一。

建立能看清差异的临时样本

使用 MySQL 8.4、支持 utf8mb4 的连接，在同一会话中完成以下片段。临时表属于当前会话；不要把其名称替换为生产表后整段执行。示例把原始字段与清理字段分开，避免在试验中覆盖来源值。

-- 记录实际服务版本，并让中文样本使用 utf8mb4。
SELECT VERSION();
SET NAMES utf8mb4;

-- 仅创建会话临时表，不修改真实业务表。
CREATE TEMPORARY TABLE space_cleanup_demo (
    id INT PRIMARY KEY,
    raw_name VARCHAR(120) NULL,
    clean_name VARCHAR(120) NULL
) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4;

-- CHAR(9) 与 CHAR(10) 分别构造制表符和换行，避免依赖反斜杠转义设置。
INSERT INTO space_cleanup_demo (id, raw_name) VALUES
    (1, '  林   海  '),
    (2, '周 宁'),
    (3, CONCAT('许', CHAR(9), '安')),
    (4, CONCAT('江', CHAR(10), '青')),
    (5, ''),
    (6, NULL);

我会把 NULL 和空字符串一起放进样本，因为它们表达不同的业务状态：一个可能表示没有提供，另一个是已经提供但为空。用清理动作顺手把两者合并，往往比多留一个空格更难恢复原意。

先预览压缩规则，再选择是否 TRIM

-- 第一列仅压缩重复普通空格；第二列另加首尾普通空格清理。
SELECT id,
       raw_name,
       HEX(raw_name) AS raw_hex,
       REGEXP_REPLACE(raw_name, ' {2,}', ' ') AS collapsed_name,
       TRIM(REGEXP_REPLACE(raw_name, ' {2,}', ' ')) AS trimmed_name
FROM space_cleanup_demo
ORDER BY id;

按这条规则，样本 1 的多个普通空格会压缩，只有加 TRIM 的表达式才去掉两端空格；样本 2 保留原有单空格；样本 3、4 的制表符和换行不在匹配范围内；空字符串保持为空，NULL 仍为 NULL。这些是表达式的预期语义，不是伪造的数据库输出截图。

HEX() 是辅助辨认不可见字符的文字工具：普通空格对应十六进制 20，制表符为 09，换行为 0A。客户端显示时看着“都是一段空白”，不代表它们是同一个字符。

REGEXP_REPLACE 省略 occurrence 时默认替换全部匹配，不需要再加其他语言常用的 g 参数。显式设置 occurrence 为 1 则只处理第一个匹配片段，不适合这里的全字段清理目标。

用事务试写，原值继续保留

确定预览符合业务语义后，才给 clean_name 赋值。下面在 InnoDB 临时表上演示事务试写，并以 ROLLBACK 结束，便于重复实验；创建表在事务之前完成，不要把 DDL 当成可以随意一起回滚的普通更新。

-- 在临时样本上写入清理字段，不覆盖 raw_name。
START TRANSACTION;

UPDATE space_cleanup_demo
SET clean_name = REGEXP_REPLACE(raw_name, ' {2,}', ' ')
WHERE id BETWEEN 1 AND 6;

-- 在当前事务中对照原值和清理值，HEX 帮助辨认不可见字符。
SELECT id, HEX(raw_name) AS raw_hex, HEX(clean_name) AS clean_hex
FROM space_cleanup_demo
ORDER BY id;

-- 示例撤销上述 UPDATE；真正保留更新需在确认后选择 COMMIT。
ROLLBACK;

实际集成可先把同样的表达式放到导入预览或展示层查询中。若最终要更新历史字段，应保留可恢复的原值、按主键范围分批，并考虑并发写入、唯一约束及锁等待。比如两个名称在清理后变成相同值，是否允许合并，属于业务规则，正则不会替你决定。

不要把示例的 id 范围换成一个没有限制的全表更新。大字段和大表上的正则计算需要安排负载；一次处理多少行，应根据实际执行情况和事务规模决定，本文没有虚构通用吞吐指标。

制表符和换行也要清理时怎么办？

如果业务明确要求把各类空白都压成普通空格，可另行采用较宽的 [[:space:]]+。它的范围超出普通空格，可能把换行压掉，因此多行备注不应默认使用。

-- 仅在业务允许合并空白字符时预览此变体，不直接 UPDATE。
SELECT id,
       raw_name,
       TRIM(REGEXP_REPLACE(raw_name, '[[:space:]]+', ' ')) AS normalized_name
FROM space_cleanup_demo
ORDER BY id;

全角空格、不换行空格以及其他 Unicode 空白要按实际数据补样本，结合当前 MySQL 使用的 ICU 正则语义确认。不要把“视觉上为空白”直接等同于“模式一定覆盖”。如来源是二进制列，也不应假设正则能按普通字符列直接处理，应先确定其编码与字段类型。

只有首尾空格，用 TRIM 就够了吗？

是的，如果规则只要求去除首尾普通空格，直接用 TRIM 更清楚。它不会压缩字段中间的连续空格，也不应被当作删除所有 Unicode 空白的通用函数。

NULL 能顺便改为空字符串吗？

可以另加业务转换，但不建议无意中这样做。本项目保留 NULL；如需转换，先约定“缺失”和“空值”是否等价，并单独记录这条规则。

重复清理会一直改变结果吗？

在相同字符规则下，把连续普通空格压成一个具有幂等性，重复应用不会继续缩减已经留下的单空格。集成时可把这一点、NULL 保留、换行保留和首尾规则作为验收条件。对我来说，小型清理项目的完成标准是规则能被解释和复用，而不是字段看起来更整齐。

-- 结束独立示例后清理会话临时表。
DROP TEMPORARY TABLE space_cleanup_demo;

参考：MySQL 正则表达式与 REGEXP_REPLACE、字符串函数与 TRIM。