to_char货币格式化失效因依赖nls设置，需用'l'或显式符号；百分数须先×100再格式化；跨库不兼容，业务层格式化更可靠；注意类型匹配与隐式转换陷阱。
TO_CHAR 货币格式化：为什么 $1234.56 变成 $1,234.56 有时失效
Oracle 的 TO_CHAR 支持货币符号和千位分隔符，但默认行为依赖数据库的 NLS_CURRENCY 和 NLS_NUMERIC_CHARACTERS 设置，不是写死的。直接用 '$999,999.99' 可能显示为 $ 1234.56（带空格）或完全不显示符号。
- 必须显式指定货币符号：用
'L999,999.99'（L表示本地货币符号），或硬编码'$999,999.99'—— 后者在多语言环境易出错 - 小数位不足时会补零，但若数值本身为
NULL，TO_CHAR返回空字符串，不是$0.00，需配合NVL处理 - 千位分隔符是否生效，取决于
NLS_NUMERIC_CHARACTERS中的分组符设置；若设为'.,'（常见于欧洲），','就是小数点，'.'才是千分位，此时'999,999.99'格式会报错 - 示例：
SELECT TO_CHAR(NVL(salary, 0), 'L999G999D99', 'NLS_CURRENCY=''$'' NLS_NUMERIC_CHARACTERS='',.''') FROM employees;
这里G和D显式指定分组/小数符，绕过数据库级配置
TO_CHAR 百分数格式化：为什么 0.123 写成 12.3% 要小心小数点位置
百分数本质是原值 × 100，但 TO_CHAR 不自动乘，必须手动处理。直接对 0.123 用 '999.99%' 会输出 0.12%（因为 % 只是字面字符），而不是预期的 12.30%。
- 正确做法：先乘 100，再格式化，如
TO_CHAR(0.123 * 100, '990.00') || '%' - 注意精度截断：
0.12345 * 100 = 12.345，用'990.00'会四舍五入为12.35；若需截断，改用TRUNC(0.12345 * 100, 2) - 负百分数要留足符号位：用
'S990.00%'（S表示符号前置），否则-12.3可能变成12.3%（右对齐空格占位） - 避免
'FM990.00%'中的FM（fill mode）去掉前导空格的同时，也去掉了负号前的空格——FM对S无效，负数仍会显示为-12.30%，没问题；但若用MI（负号后置），FM会把负号吞掉
跨数据库兼容性：PostgreSQL / MySQL 用户别硬套 TO_CHAR
只有 Oracle 和部分兼容 Oracle 模式的数据库（如 some versions of TimescaleDB）支持标准 TO_CHAR 货币/百分数格式模型。PostgreSQL 有 TO_CHAR，但格式符不同（如用 'L999G999D99' 会报错，得用 'L999,999.99' 且需 lc_monetary 配置）；MySQL 根本没有 TO_CHAR，得用 FORMAT() 或拼接。
- Oracle：
TO_CHAR(val, 'L999G999D99', 'NLS_CURRENCY=''€''') - PostgreSQL：
TO_CHAR(val, 'L999,999.99')+SET lc_monetary = 'de_DE.UTF-8'; - MySQL：
CONCAT(FORMAT(val * 100, 2), '%')（百分数）、CONCAT('€', FORMAT(val, 2))（欧元） - 统一做法：业务层格式化更可控，SQL 层只传原始数值，避免因数据库配置漂移导致前端显示异常
容易被忽略的隐式类型转换陷阱
TO_CHAR 的第二个参数（格式模型）是字符串，但第一个参数如果是表达式（如 salary / bonus），结果类型可能为 NUMBER、BINARY_FLOAT 甚至 INTERVAL，而格式模型不匹配会导致 ORA-01722（invalid number）或静默截断。
- 检查源字段类型：
DESCRIBE employees看salary是NUMBER(8,2)还是NUMBER；后者在除法后可能产生超长小数，'999.99'会截掉多余位，不报错但失真 - 避免混合精度运算：
TO_CHAR(100/3, '999.99')返回33.33（四舍五入），但100/3实际是33.333333...，若业务要求向下取整，得先FLOOR(100/3) - 日期型误用：有人把
SYSDATE传给货币格式，TO_CHAR(SYSDATE, '$999,999.99')不报错但返回乱码（如$000,000.00），因为日期转数字有默认规则，非预期
