REPLACE() 不适合纯前缀替换，因其是全局无位置感知的子串匹配，无法限定仅开头替换，易误删中间或结尾的相同子串；而 SUBSTRING()+CHAR_LENGTH()+WHERE LIKE 才能精准锚定前缀位置。
直接说结论：用 REPLACE() 处理“中间或任意位置”的子串替换更自然；但想批量修改前缀（比如统一加 /api/v2、删掉开头的 temp_），CONCAT() 或 SUBSTRING() 配合条件判断才可控，硬套 REPLACE() 容易误伤。
为什么 REPLACE() 不适合纯前缀替换
REPLACE() 是全局子串匹配，不区分位置。比如字段值是 'temp_user_123'，执行 REPLACE(username, 'temp_', '') 看似能删前缀，但如果某条记录是 'admin_temp_role'，也会被误删成 'admin_role'。
- 它不认“开头”，只认“出现”——哪怕在中间、结尾、重复多次，全替
- 无法限制只换第一次，也不能加位置锚点（如正则里的
^） - 若前缀本身含特殊字符（如
%、_），WHERE 条件里用LIKE还得转义，容易漏判
真正安全的前缀替换写法：用 SUBSTRING() + LENGTH() 判断
核心思路：先确认字段是否以目标前缀开头，再决定怎么截或拼。
- 删前缀（如去掉
old_）：UPDATE users SET username = SUBSTRING(username, LENGTH('old_') + 1) WHERE username LIKE 'old_%'; - 加前缀（如统一加
new_）：UPDATE users SET username = CONCAT('new_', username) WHERE username NOT LIKE 'new_%'; - 替换前缀（如
dev_→prod_）：UPDATE users SET username = CONCAT('prod_', SUBSTRING(username, LENGTH('dev_') + 1)) WHERE username LIKE 'dev_%';
注意：所有操作都必须带 WHERE 条件过滤，否则会无差别更新整列（包括 NULL 或不匹配的行）。
CONCAT() 的坑：NULL 值会让整结果变 NULL
如果字段本身可能为 NULL，直接 CONCAT('prefix_', column) 会导致该行更新后变成 NULL，而不是预期的 'prefix_'。
- 正确兜底方式：
CONCAT('prefix_', IFNULL(column, '')) - 更简洁写法（推荐）：
CONCAT_WS('', 'prefix_', column)——CONCAT_WS()自动跳过NULL参数 - 别依赖隐式转换：像
CONCAT('id:', id)中id是数字，MySQL 会转成二进制字符串，可能影响排序或比较，显式用CAST(id AS CHAR)更稳
执行前必须做的三件事
前缀类更新看似简单，但一旦出错很难回滚，尤其跨环境同步时。
- 先用
SELECT预览：SELECT id, username, CONCAT('new_', username) AS new_name FROM users WHERE username LIKE 'old_%' LIMIT 10; - 务必包在事务里：
START TRANSACTION; UPDATE ... ; SELECT ROW_COUNT(); COMMIT;（别忘了查影响行数） - 大表加索引：WHERE 条件字段（如
username）没索引？全表扫描可能锁表几分钟——加INDEX(username)再操作
最常被忽略的是：不同字符集下 LENGTH() 和 CHAR_LENGTH() 行为不一致。UTF8MB4 中一个中文占 4 字节，但 LENGTH('你好') 返回 8，而 CHAR_LENGTH('你好') 才是 2。前缀操作一律用 CHAR_LENGTH()，避免字节级计算出错。
