MySQL 8.0+ 的 FORMAT() 函数不能直接转货币，仅返回带千分位和小数位的字符串（如 "12,345.68"），不包含货币符号、负数括号格式或本地化语义，需配合 CONCAT、CASE 等手动处理才能模拟货币显示。
MySQL 8.0+ 的 FORMAT() 函数能直接转货币吗？
不能。虽然 FORMAT() 可以加千位分隔符和小数位，但它只返回字符串，不带货币符号（如 $ 或 ¥），也不处理负数的括号格式、本地化小数点/分隔符等货币语义。它本质是数值格式化工具，不是货币格式化函数。
常见误用：SELECT FORMAT(12345.678, 2) 得到 "12,345.68" —— 这不是货币字符串，只是带逗号的数字。
- 若需美元符号，得手动拼接：
CONCAT('$', FORMAT(12345.678, 2)) - 若值为负（如
-12345.678），FORMAT()返回"-12,345.68"，但会计场景常需"(12,345.68)"，这得靠CASE+REPLACE手动处理 -
FORMAT()使用服务器 locale 决定小数点和千分位符号，无法在 SQL 层指定（比如强制用,做小数点），跨环境易出错
PostgreSQL 没有内置 FORMAT()，该用什么？
PostgreSQL 不提供 FORMAT() 函数；它的等价方案是 to_char()，且对货币支持更直接。
示例：SELECT to_char(12345.678, 'L99,999,999.00')（L 表示本地货币符号）——但注意：L 取决于当前 lc_monetary 设置，不是硬编码。想固定用美元，得写 '$99,999,999.00'。
- 负数默认显示为
$-12,345.68；要括号格式，用'$99,999,999.00MI'（MI表示 trailing minus，配合FM可抑制空格） -
to_char()的模板字符严格区分大小写：9是数字占位符，0是强制补零，,和.是字面分隔符 - 如果字段可能为
NULL，to_char(NULL, ...)返回NULL，不会报错，但要注意业务逻辑是否允许
SQL Server 的 FORMAT() 看似方便，为什么线上慎用？
SQL Server 2012+ 的 FORMAT(value, format_string, culture) 支持完整货币格式，例如：FORMAT(12345.678, 'C2', 'en-US') → "$12,345.68"，甚至支持 'de-DE' 得到 "12.345,68 €"。
但问题在于性能：该函数是 CLR 实现，执行开销远高于纯 T-SQL 运算，在大结果集或高频查询中会明显拖慢响应。
- 替代方案：用
STR()+ 字符串拼接（快但不支持 locale）或提前在应用层格式化 -
culture参数若传空或无效，会回退到会话默认，导致结果不稳定 - 日期/数字共用同一函数名，容易混淆签名；比如
FORMAT(GETDATE(), 'C2')会报错，因为日期不能用货币格式
跨数据库兼容的“准货币格式”怎么写？
没有银弹。若必须在 SQL 层统一输出带符号、千分位、两位小数的字符串，只能取交集能力：用 ROUND() + 字符串拼接 + 条件逻辑，放弃 locale 和负数括号。
通用写法（以 MySQL 为例）：
SELECT CONCAT(
'$',
REPLACE(
FORMAT(ABS(12345.678), 2),
',',
','
),
CASE WHEN 12345.678 ——但这只是模拟，真正括号格式还得反转逻辑顺序，且无法处理千分位嵌套。
- 最稳妥的做法：SQL 只做
ROUND(x, 2)，把原始数值交给应用层（Python 的f"{x:,.2f}"、JS 的Intl.NumberFormat）处理 - 如果报表工具（如 Power BI、Tableau）支持，优先用其内置货币格式，而非在 SQL 里硬编码
- 所有数据库的字符串拼接对
NULL都敏感：CONCAT('$', NULL)→NULL，务必用COALESCE(col, 0)或IFNULL()防断
实际项目里，SQL 层的“货币格式”往往只是表象需求，背后是展示一致性、多语言支持、审计合规等约束——这些单靠一个函数根本兜不住。
