TRANSLATE并非比REPLACE更高效，而是解决不同问题：它执行字符级一对一映射，每个字符单独查表替换；REPLACE执行子串级滑动匹配替换；二者机制不同、不可互换。
TRANSLATE 并不比 REPLACE “更高效”，它只是解决不同问题的工具——强行拿它替代 REPLACE 很可能出错，而用对了场景，它确实更简洁、更可靠。
TRANSLATE 是字符级映射，不是子串替换
这是最常误解的点：TRANSLATE('ababab', 'ab', 'XY') 的结果是 'XYXYXY'，不是因为把子串 'ab' 替换成了 'XY'，而是每个 'a' 单独映射为 'X'，每个 'b' 单独映射为 'Y'。而 REPLACE('ababab', 'ab', 'XY') 才是真正按连续子串匹配并替换。
关键区别在于：
-
TRANSLATE对字符串中**每一个字符**单独查表：是否在from_string中？是，则取to_string中同位置字符（超出长度则删除该字符） -
REPLACE是滑动窗口扫描：从左到右找**连续出现的search_string**，找到就整段替换成replacement_string - 当
from_string比to_string长时，多出的字符会被直接删掉，例如TRANSLATE('abc', 'abcd', 'XY')→'XYc'
真正体现“高效”的典型场景：白名单过滤
比如只保留电话字段中的数字，一行搞定：
SELECT TRANSLATE(tel, '0123456789' || tel, '0123456789') AS digits_only FROM users;
原理很直接：把所有数字 + 原字符串拼成 from_string，这样原字符串里所有非数字字符都落在拼接后的前半部分，但 to_string 中没有对应位置，于是被删；而数字本身有映射，得以保留。
这种写法比嵌套 10 层 REPLACE 或正则更轻量，也比递归 CTE 更快——因为它是一次性字符查表，无循环、无递归、无模式匹配开销。
类似地，清理标点符号（只留字母+数字）：
- 构造
to_string = 'abcdefghijklmnopqrstuvwxyz0123456789' - 令
from_string = to_string || '!@#$%^&*()_+-=[]{}|;:,.?'（把不要的字符加在后面） - 所有非白名单字符因无映射位置而被自动剔除
NULL 和空字符串行为差异大，容易踩坑
TRANSLATE 对 NULL 极其敏感：任一参数为 NULL，整条结果就是 NULL。而 REPLACE 相对宽容——replacement_string 为 NULL 或空串时，只是删掉匹配内容，不影响其他逻辑。
常见错误：
- 没做
IS NULL判断就直接套TRANSLATE(col, ...)，导致整列变NULL - 误以为
to_string可以为空，实际只要to_string是空串或NULL，结果必为NULL - 在
WHERE子句里用TRANSLATE(col, ...)做条件判断，却没意识到它会把含NULL的行整个过滤掉（而非跳过）
和 REPLACE 嵌套等价但不可互换
TRANSLATE('2*[3+4]/{7-2}', '[]{}', '()()') 等价于四层嵌套 REPLACE：
SELECT REPLACE(REPLACE(REPLACE(REPLACE('2*[3+4]/{7-2}', '[', '('), ']', ')'), '{', '('), '}', ')');
但注意：如果用 REPLACE 替换 '[' 后又出现新 '['（比如替换结果里生成了 '['），后续 REPLACE 还会再处理；而 TRANSLATE 保证每个字符只处理一次，不会二次替换。
所以它的“高效”体现在语义确定性上——你永远知道某个字符只会被映射一次，不会因嵌套顺序或中间结果产生歧义。这点在清洗 GeoJSON、标准化括号、统一引号等结构化文本时特别关键。
真正容易被忽略的是：它不支持 Unicode 增补字符（如某些 emoji 或生僻汉字）的跨码点映射，且始终感知 SC 排序规则；如果你的字段用了 Latin1_General_100_CI_AS_SC_UTF8，但 from_string 里混入了未归一化的 UTF-8 字节序列，结果可能不符合预期。
