to_number直接处理带逗号字符串会报ora-01722错误，需用格式模型如'fm999g999g999d99'显式声明千分位和小数点；空字符串或空格须trim+正则校验；生产环境建议etl清洗或封装函数，避免oracle特有语法影响可移植性。
TO_NUMBER直接处理带逗号的字符串会报错
Oracle 的 TO_NUMBER 默认不识别千分位逗号，比如 '1,234.56' 直接转换会抛出 ORA-01722: invalid number。这不是数据问题，是格式解析失败——函数按纯数字+小数点规则匹配，遇到逗号就立刻中断。
用格式模型显式声明千分位和小数点位置
必须用第二个参数（格式模型）告诉 Oracle：逗号是分组符，点是小数点。关键不是“去掉逗号”，而是“让 Oracle 理解这个逗号合法”。
-
TO_NUMBER('1,234.56', '999,999.99')可行，但长度硬编码，超长就报错 - 更健壮写法：
TO_NUMBER('1,234.56', 'FM999G999G999D99')，其中G表示千分位分隔符（默认为逗号），D表示小数点，FM去除前导空格和尾部填充 - 注意：格式模型中的
G和D必须与实际字符串中的符号一致；如果数据库 NLS 设置把千分位设成句点（如欧洲格式），就得用TO_NUMBER('1.234,56', 'FM999G999G999D99')并确保NLS_NUMERIC_CHARACTERS匹配
NULL 或空字符串时 TO_NUMBER 会报错，必须提前过滤
TO_NUMBER(NULL) 返回 NULL 没问题，但 TO_NUMBER('') 或 TO_NUMBER(' ') 会触发 ORA-01722。不能依赖函数自身容错。
- 安全写法：先用
TRIM清空格，再用CASE WHEN REGEXP_LIKE(TRIM(col), '^[-+]?[0-9,]+\.?[0-9]*$') THEN TO_NUMBER(...) ELSE NULL END - 更轻量做法：用
TRANSLATE(col, ',.', ' ')把逗号和点全换成空格，再判断是否REGEXP_LIKE(..., '^[[:space:][:digit:]-]+$')，避免正则过度复杂 - 生产环境建议封装成函数，避免每处都写冗长判断逻辑
性能和可移植性提醒
带格式模型的 TO_NUMBER 比纯数字转换慢约 2–3 倍（实测百万行差异明显），且该写法只在 Oracle 有效。如果后续可能迁移到 PostgreSQL 或 SQL Server，别把逻辑耦合进 SQL 层。
- 批量清洗数据时，优先在 ETL 阶段用 Python/Java 去掉千分位，入库存纯数字
- 若必须 SQL 内处理，把格式模型写成变量或 WITH 子句常量，方便统一调整
- 特别注意：
TO_NUMBER('1,234.56', '999,999.99')在数值超模板位数时静默截断或报错，务必验证边界值
真正麻烦的不是语法，是不同系统间千分位符号、小数点符号、负号位置（如会计习惯的括号负数）混在一起时，一个正则或一个格式模型根本 cover 不住所有 case。
