直接用 substring(phone, 1, 11) 会错误截取前导零，正确做法是先清洗干扰字符再取右11位；拼接国家码需先判断是否已存在；执行顺序和数据库差异易引发错误，须加长度保护与预览验证。

为什么直接用 SUBSTRING 拼接会丢掉前导零

很多数据库里手机号存成 VARCHAR，但原始数据混入了空格、短横线、括号，甚至开头多了“86”或“+86”。想统一成 11 位纯数字时，如果只写 SUBSTRING(phone, 1, 11)，遇到像 '013812345678'（12 位，开头是 0）就会截成 '01381234567'——看着像对的，其实是错的。真正要的是去掉干扰字符后取最后 11 位，不是从头硬切。

实操建议：

• 先用 REPLACE 清理常见干扰符：REPLACE(REPLACE(REPLACE(phone, ' ', ''), '-', ''), '(', '')
• 再用 TRIM 去掉首尾空格和加号：TRIM(BOTH '+' FROM TRIM(phone))
• 最后用 SUBSTRING 取右 11 位：SUBSTRING(cleaned, -11)（MySQL 支持负数起始位；PostgreSQL 需用 RIGHT(cleaned, 11)）

用 CONCAT 补全缺失的国家码是否安全

有些字段只有 10 或 11 位数字，但没带“86”。直接 CONCAT('86', phone) 看似简单，实际风险很大：如果原字段已经含“86”，就会变成“8686……”；如果含“+86”，拼完是“86+86……”。

实操建议：

• 先判断是否已含国家码：CASE WHEN phone LIKE '86%' OR phone LIKE '+86%' THEN phone ELSE CONCAT('86', phone) END
• 更稳妥的做法是先清洗再判断长度：LENGTH(TRIM(REPLACE(REPLACE(phone, '+', ''), '-', ''))) = 11，满足才不补
• 注意：SQL Server 不支持 CONCAT 旧版本，得用 + 拼接，且任一操作数为 NULL 会导致整结果为 NULL，需套 ISNULL()

UPDATE 语句中嵌套 SUBSTRING 和 CONCAT 的执行顺序陷阱

写成 UPDATE user SET phone = CONCAT('86', SUBSTRING(REPLACE(phone, ' ', ''), 1, 11)) 看起来一气呵成，但执行时是“先算右边表达式，再赋值”，而 SUBSTRING 若输入为空或长度不足，MySQL 返回空字符串，PostgreSQL 报错 substring error，SQL Server 报 Invalid length parameter。

实操建议：

• 加长度保护：SUBSTRING(cleaned, GREATEST(1, LENGTH(cleaned) - 10), 11)（确保起始位置 ≥ 1）
• 用 CASE 过滤异常长度：CASE WHEN LENGTH(cleaned) >= 11 THEN SUBSTRING(cleaned, -11) ELSE NULL END
• 务必在真实环境前加 SELECT 预览：SELECT id, phone, CONCAT('86', SUBSTRING(...)) AS fixed_phone FROM user WHERE ... LIMIT 10

不同数据库对中文手机号字段的隐式转换风险

某些 MySQL 表用 utf8mb4 但字段定义是 VARCHAR(11)，当存入含中文括号（如“（138）12345678”）时，实际字节数超限，可能被静默截断——SUBSTRING 拿到的已是残缺字符串，再怎么拼也救不回来。

实操建议：

• 检查原始字段最大长度：SELECT MAX(LENGTH(phone)) FROM user，若远大于 11，说明有脏数据
• 清洗前先备份：ALTER TABLE user ADD COLUMN phone_raw VARCHAR(50)，再 UPDATE user SET phone_raw = phone
• Oracle 用户注意：SUBSTR 第一个参数是 1-based，但负数不支持；必须用 SUBSTR(phone, LENGTH(phone) - 10, 11)

批量修正手机号最麻烦的从来不是函数调用，而是你永远不知道原始数据里藏着几个全角空格、软连字符，或者某个运营同事手抖多输了一个“０”（Unicode U+FF10）。动手前先看一眼 SELECT HEX(phone) FROM user LIMIT 5，比写十行 REPLACE 更管用。