FORMAT函数仅用于最终展示，返回nvarchar类型字符串，不可参与数值计算；高并发下性能差，跨数据库语法差异大，应优先前端格式化或使用CONVERT/CAST。
FORMAT 函数在 SQL Server 中的数值格式化能力有限
SQL Server 的 FORMAT 函数确实能按指定模式输出带千分位、小数位、货币符号的字符串，但它本质是「转成字符串」而非「数值格式化」——返回值类型为 nvarchar，无法参与后续数值计算。一旦你写 SELECT FORMAT(price, 'C2') FROM orders，结果列就不再是数字，排序、求和、WHERE price > 100 都会出错或隐式转换失败。
常见错误现象：ORDER BY FORMAT(amount, 'N2') 看似按数值排序，实则按字符串字典序（比如 "10.50" 排在 "9.99" 后面）；更隐蔽的是，某些 BI 工具把该列识别为文本，自动禁用聚合操作。
- 只在最终展示层（如报表、导出视图）使用
FORMAT，绝不用于中间计算或 WHERE/HAVING 条件 - 若需兼顾可读性与可计算性，优先用
CONVERT+ 样式码（如CONVERT(varchar, amount, 1)对应千分位+两位小数），它更快且不依赖 .NET 运行时 -
FORMAT在高并发查询中性能明显低于原生转换函数，因每次调用都触发 CLR 上下文切换
MySQL 和 PostgreSQL 没有 FORMAT 函数，得换思路
MySQL 8.0+ 提供 FORMAT() 函数，但行为和 SQL Server 不同：它只做四舍五入+加千分位，不支持自定义模板（如货币符号、百分比）。PostgreSQL 则完全没这个函数，必须用 to_char() 配合格式模型。
使用场景差异明显：FORMAT(12345.678, 2)（MySQL）返回 "12,345.68"；而 PostgreSQL 要写 to_char(12345.678, 'FM99,999.00')，其中 FM 去除前导空格，9 表示数字占位符，, 是千分位符——漏掉 FM 可能导致字段左对齐留空格，影响前端对齐显示。
- MySQL 的
FORMAT第二参数是小数位数，不能传字符串模板；传负数会报错 - PostgreSQL 的
to_char对 null 输入默认返回空字符串，而 SQL Server 的FORMAT(NULL, 'C')返回NULL，跨数据库迁移时要注意空值处理一致性 - 所有数据库中，这类函数均无法利用索引——别在 WHERE 子句里对数值列套用格式化函数
替代方案：前端格式化更安全也更灵活
真正需要「美化输出」的场景，绝大多数发生在应用层或报表工具里。把 12345.6789 交给后端格式化成 "¥12,345.68"，不如直接传原始数值，由 JavaScript 的 Intl.NumberFormat 或 Python 的 f"{x:,.2f}" 处理。这样既避免 SQL 层类型污染，又支持动态语言/地区切换。
容易被忽略的点：SQL 层格式化会把区域规则（如小数点是 . 还是 ,）硬编码进语句，而前端可实时读取用户浏览器 navigator.language 或服务端配置，自动适配德语区的 "12.345,68 €"。
- BI 工具（如 Power BI、Tableau）内置数字格式设置，无需 SQL 改动即可统一调整列显示样式
- 如果必须 SQL 输出字符串，考虑用计算列（SQL Server）或生成列（MySQL 5.7+）预存格式化结果，并为其建立索引（仅当该字符串列会被频繁 WHERE 查询时）
- 警惕 ORM 框架的自动类型转换——某些框架看到
FORMAT就强制把整列当字符串映射，导致业务代码里误用+拼接而非数值相加
小数精度丢失比格式难看更致命
用 FORMAT 或 to_char 前，先确认源字段类型。如果存的是 float 或 real，哪怕显示成 "1.10"，实际值可能是 1.0999999999999999。此时格式化只是掩盖问题，不是修复问题。
典型表现：金额列用 FORMAT(money, 'C2') 显示正常，但导出 Excel 后发现小计对不上——因为底层二进制浮点误差在多次运算后累积暴露了。
- 财务类数值一律用
decimal(p,s)或numeric，例如decimal(19,4)表示最多 19 位总长、4 位小数 - SQL Server 中
CONVERT(varchar, CAST(1.1 AS decimal(10,2)), 1)比FORMAT(1.1, 'C2')更可靠，前者基于精确十进制，后者可能受当前会话LANGUAGE设置影响 - 测试时别只看 SELECT 结果，用
DATALENGTH()查返回字符串实际字节数，确认没混入不可见字符（尤其to_char在某些 locale 下插入窄空格）
