FORMAT函数返回nvarchar字符串，不可参与数值计算或排序；仅限最终展示层使用，且需显式指定culture避免区域差异，性能差于CONVERT，跨库不兼容。
FORMAT函数返回的是字符串，不是数字
调用 FORMAT(1234567.89, 'N2') 看起来很干净，但结果是 nvarchar 类型的 '1,234,567.89'，它不能再参与加减、WHERE amount > 1000 或 ORDER BY 数值排序。常见翻车点：写成 ORDER BY FORMAT(price, 'N2')，结果按字符串字典序排，'999.99' 会排在 '10000.00' 后面。
如果你需要排序或计算，必须保留原始数值列；格式化只该出现在最终 SELECT 列表里，且仅用于展示目的（比如导出 Excel、报表视图）。
格式字符串写法和常见陷阱
FORMAT 的第二个参数是格式模板，不是小数位数——这点和 MySQL 完全不同。例如：
-
'N0'：千分位 + 零位小数（1234567→'1,234,567'） -
'N3'：千分位 + 三位小数（1234567.8→'1,234,567.800'，自动补零） -
'C2'：本地货币格式，受会话LANGUAGE或显式culture影响（FORMAT(1234.5, 'C2', 'de-DE')得'1.234,50 €'） -
'0,0.00'：自定义模式，0表示强制占位，,是千分位符，.是小数点——但注意，这种写法不支持负数前缀控制，也不处理空值逻辑
漏传 culture 参数时，它依赖当前会话语言设置，跨库迁移或 BI 工具连接时容易输出错乱（比如美式逗号变德式点号），线上环境务必显式指定，如 'en-US'。
性能差、高并发下慎用
FORMAT 底层调用 .NET 的 String.Format，每次执行都触发 CLR 上下文切换，实测在百万行查询中比 CONVERT(varchar, CAST(x AS money), 1) 慢 5–10 倍。它不适合出现在核心交易 SQL、ETL 中间表构建或视图定义里。
替代方案更稳：
- 要千分位+两位小数：用
CONVERT(varchar, CAST(amount AS money), 1)（快、固定 en-US 格式） - 要去掉小数部分的
'.00'：加REPLACE(..., '.00', '') - 要兼容 null：原生
CONVERT对 null 返回NULL，而FORMAT(NULL, 'N2')也返回NULL，行为一致，但性能差太多
跨数据库不可移植，别当通用解法
FORMAT 是 SQL Server 特有函数。MySQL 的 FORMAT() 只接受数值和小数位数（如 FORMAT(1234.567, 2)），不支持模板字符串；PostgreSQL 根本没有这个函数，得用 to_char(amount, 'FM9,999,999.00')，且 FM 不加会导致左侧空格，前端对齐出问题。
如果项目未来可能换库，或需对接多个数据源，所有格式化逻辑应移出 SQL，交给应用层（Python 的 f"{x:,.2f}"、JS 的 toLocaleString()）处理——SQL 只管算，不管“怎么看起来好看”。
真正难的不是写对 FORMAT，而是记住它在哪能用、在哪不能碰，以及为什么有时候明明格式对了，排序却错了。
