直接用 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 更管用。
