Oracle TO_CHAR函数的千分位符号由NLS_NUMERIC_CHARACTERS参数决定，而非格式模型；固定使用逗号需统一设置会话NLS，自定义符号（如|）须用REGEXP_REPLACE等手动处理，但性能差且难维护。
TO_CHAR数字格式化中千分位符号的控制逻辑
Oracle 的 TO_CHAR 函数本身不直接支持「指定千分位符号」（比如用空格或逗号以外的字符），它只认当前会话的 NLS_NUMERIC_CHARACTERS 设置。也就是说，你看到的千分位符（如逗号、句点、空格）不是由格式模型决定的，而是由数据库或会话级的区域设置决定的。
常见误解是以为写 '9,999.99' 就能强制输出逗号——其实这个逗号只是格式占位符，真正显示什么，取决于 NLS_NUMERIC_CHARACTERS 中定义的千分位分隔符和小数点符号。
- 默认情况下，美式环境返回
NLS_NUMERIC_CHARACTERS = ',.'→ 千分位是逗号 - 德语环境可能是
' .,'→ 千分位是空格，小数点是逗号 - 如果你改了会话设置：
ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ' ''.'，那TO_CHAR(1234567.89, '9,999,999.99')会输出1 234 567.89
想固定用逗号作千分位？必须先确认并统一NLS设置
不能靠改格式串绕过 NLS，只能靠控制环境。生产环境中尤其要注意：应用连接时可能未显式设置 NLS，导致同一 SQL 在不同客户端（SQL*Plus / JDBC / ODBC）返回不同分隔符。
安全做法是在每次使用前显式设置会话级参数：
ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ',.';
或者在 JDBC 连接字符串里加：?oracle.jdbc.defaultNlsParameters=true&oracle.jdbc.nlsNumericCharacters=%2C.（注意 URL 编码）
-
TO_CHAR(1234567.89, '9,999,999.99')在正确 NLS 下才稳定输出1,234,567.89 - 如果格式串里写了
'9G999G999D99'，G和D是等价于千分位/小数点的通用占位符，但依然受 NLS 控制，不是硬编码 - 不要用
'999,999,999.99'去“猜”分隔符——一旦 NLS 变了，结果就不可控
需要完全自定义符号（比如用|或*）？得绕开TO_CHAR做字符串拼接
Oracle 原生 TO_CHAR 不允许把千分位替换成任意字符。若业务强要求输出 12|345|678.90，只能手动拆解：
先转成无格式字符串，再按位插入分隔符：
SELECT
REGEXP_REPLACE(
TO_CHAR(FLOOR(12345678.9), 'FM999999999'),
'(\d{3})(?=\d)',
'\1|'
) || '.' || TO_CHAR(12345678.9 - FLOOR(12345678.9), 'FM00') AS formatted
FROM DUAL;这方法脆弱：依赖正则支持、位数固定、小数部分要单独处理。更稳妥的是在应用层（Java/Python）做格式化，数据库只负责传原始数值。
- 正则中的
(?=\d)是正向先行断言，确保只在每三位数字左侧插入，避免末尾多加 -
FM格式修饰符必须加，否则TO_CHAR会补空格，干扰正则匹配 - 超过 12 位数时，正则
\d{3}可能匹配错位，需根据实际最大长度调整
性能与可维护性提醒
用 REGEXP_REPLACE 实现自定义千分位，在大数据量聚合查询中会有明显性能损耗，比原生 TO_CHAR 慢 3–5 倍。而且这类逻辑藏在 SQL 里，后续交接或排查时容易被忽略。
真正该问的是：这个格式到底在哪用？如果是报表导出，交给 BI 工具（如 Oracle Analytics 或 Tableau）处理更合理；如果是 API 返回，由后端服务统一格式化更可控。
别让数据库承担本不属于它的展示职责——尤其是当「看起来只是换个符号」的时候，背后牵扯的是 NLS 一致性、正则可靠性、以及谁该为格式错误负责。
