format函数仅用于最终展示，返回nvarchar字符串且不可参与数值计算；高并发下因clr上下文切换性能差；跨数据库语法不兼容，应优先前端格式化或用convert/cast替代。
FORMAT 函数在 SQL Server 中确实能快速把数字变成带千分位、货币符号或自定义小数位的字符串，但它不是“安全的格式化工具”——用错地方会拖慢查询、破坏排序、甚至让 WHERE 条件失效。
FORMAT 的基本用法和参数陷阱
FORMAT 是 SQL Server 2012+ 引入的函数，语法为 FORMAT(value, format[, culture])，但三个参数都有坑：
- 第一个参数
value必须是数值、日期或时间类型；传NULL直接返回NULL，不是空字符串 - 第二个参数
format是 .NET 格式字符串，不是 SQL 原生语法：-
'N2'→ 带千分位 + 两位小数（如'12,345.68'） -
'C2'→ 本地货币格式（受当前会话LANGUAGE或显式culture控制） -
'#,##0.00'→ 自定义数字模板，注意逗号是千分位符，不是小数点
-
- 第三个参数
culture可选，但一旦指定必须是合法 .NET 区域名（如'zh-CN'），拼错就返回NULL，不报错
常见错误现象：
-
SELECT FORMAT(12345.678, 'C', 'zh-CN')在英文系统里可能仍显示$12,345.68，因为lc_monetary或 SQL Server 的区域设置未同步 -
FORMAT(-1234.5, 'C')默认输出括号负号：(¥1,234.50)，不是-¥1,234.50
为什么 FORMAT 在高并发下会变慢
FORMAT 底层调用 .NET CLR 运行时，每次执行都触发上下文切换，执行计划中显示为标量函数调用。实测上万行数据时：
前端设计优化skill
下载
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
- CPU 使用率明显升高，尤其在 OLTP 场景中叠加 JOIN 或 GROUP BY
- 无法内联优化，不能被查询优化器重写或下推
- 不支持在计算列、索引表达式、CHECK 约束中使用
对比方案：
-
CONVERT(VARCHAR, @num, 1)（样式码1对应千分位+两位小数）快 3–5 倍，不依赖 CLR -
STR(ROUND(@num, 2), 18, 2)加REPLACE(LTRIM(...), ' ', '')清空格，也比FORMAT稳定
FORMAT 返回的是字符串，不是数字
这是最容易被忽略的硬伤：
- 返回类型固定为
nvarchar，不能再参与数值运算：WHERE FORMAT(price, 'N2') > '100.00'→ 实际按字符串字典序比较，'99.99'会排在'100.00'后面 -
ORDER BY FORMAT(amount, 'N2')排序结果错乱（比如'1,000.00'排在'999.99'前） - BI 工具（如 Power BI、Tableau）自动识别该列为文本，禁用求和、平均等聚合
正确做法：
- 仅在最终导出视图、报表字段、SSRS 表达式中使用
- 中间计算、过滤、聚合一律用原始数值列
- 若需同时保留数值和格式化结果，用两个字段：
amount AS amount_raw, FORMAT(amount, 'C2', 'zh-CN') AS amount_formatted
真正上线前务必验证负数、零值、极小浮点数（如 0.001）和 NULL 的表现——财务类系统里，FORMAT(0, 'C') 和 FORMAT(NULL, 'C') 的差异可能直接导致对账不平。
