SQL Server 的 FORMAT 函数支持文化习惯与自定义模式格式化，但性能差、不可索引，生产环境慎用；它返回 nvarchar，需传入 value、format、culture 三参数，不改变原值仅影响显示。
SQL Server 的 FORMAT 函数能按文化习惯和自定义模式格式化数字，但性能差、不可索引，生产环境慎用。
FORMAT 在 SQL Server 中的典型用法
FORMAT 是 SQL Server 2012+ 引入的 CLR 函数，用于将数值、日期等转为带格式的字符串。它不改变数据本身，只影响显示结果。
- 必须传入三个参数：
value（待格式化的值）、format（格式字符串）、culture（可选，如'en-US'或'zh-CN'） - 数字格式字符串支持标准模式（如
'C2'表示两位小数的货币）和自定义模式（如'#,##0.00'） - 注意：返回类型始终是
nvarchar，不能直接参与数值计算
例如：
SELECT FORMAT(12345.678, 'C', 'en-US') -- → '$12,345.68'
常见格式字符串写法与陷阱
自定义数字格式中，# 表示“有则显示，无则跳过”，0 表示“强制占位”，, 是千位分隔符，. 是小数点占位符。
-
'#,##0.00'：整数部分千分位分隔，小数固定两位（12345.6→'12,345.60'） -
'00000.00'：整数不足五位补前导零（42.5→'00042.50'） -
'#,##0.###'：小数最多三位，不补零（100.5→'100.5'） - 错误写法：
'#,##0.000'作用于整数100会得'100.000'，但若只想保留有效小数，FORMAT无法自动省略尾零
为什么 FORMAT 不该用在 WHERE 或 JOIN 条件里？
FORMAT 是标量函数，每次调用都触发逐行计算，且结果无法走索引，会导致全表扫描。
- 错误示例：
WHERE FORMAT(price, 'C2') = '$99.99'—— 无法利用price列上的索引 - 更糟的是：不同
culture下货币符号、小数点可能不同（'de-DE'中是'99,99 €'），条件逻辑易错 - 替代思路：格式化应尽量下推到应用层；若必须在 SQL 层做，优先用
CONVERT+ 字符串拼接（如CONVERT(varchar, price, 1)控制小数位），或用STR()（但精度控制较弱）
兼容性与替代方案提醒
FORMAT 仅 SQL Server 和 Azure SQL 支持，PostgreSQL、MySQL、SQLite 均无此函数 —— 这意味着写死 FORMAT 的 SQL 几乎无法跨库迁移。
- MySQL 对应的是
FORMAT(num, d)，但只支持千分位和小数位，不支持自定义模板或文化参数 - PostgreSQL 推荐用
to_char(num, 'FM999,999.00')，语法更接近传统格式化，且支持本地化 - 真正需要动态文化适配时，别依赖数据库函数，让应用层用
NumberFormat（Java）、toLocaleString()（JS）等处理更可靠
最常被忽略的一点：FORMAT 的 culture 参数若写错（比如拼成 'zh-CN ' 多了个空格），会静默回退到 en-US，而错误不会报出。
