FORMAT 是 SQL Server 特有函数，MySQL 和 PostgreSQL 不支持；跨库项目应避免使用，优先客户端格式化或标准 SQL 函数替代。
FORMAT 函数在 SQL Server 中能用，但 MySQL 和 PostgreSQL 不能直接用
SQL 标准里没有 FORMAT 函数，它是 SQL Server（2012+）和 Azure SQL 的特有函数。MySQL 用 DATE_FORMAT 或 FORMAT（仅数字，且行为不同），PostgreSQL 则靠 TO_CHAR。直接在跨数据库项目里写 FORMAT(..., 'C') 很可能报错：Invalid column name 'FORMAT' 或 function format does not exist。
实操建议：
- 先确认你的数据库类型：运行
SELECT @@VERSION（SQL Server）、SELECT VERSION()（MySQL）或SELECT version()（PostgreSQL） - SQL Server 中
FORMAT是字符串函数，返回nvarchar，不能用于计算或索引，性能较差，只适合最终展示层 - 如果只是想补零、加千分位、转货币，优先考虑客户端格式化（如 C# 的
ToString("C2")或 JS 的Intl.NumberFormat），更可控也更高效
SQL Server 中 FORMAT 数字的常见写法和坑
FORMAT 对数字支持 .NET 风格格式字符串，比如 'N2' 表示带千分位和两位小数，'C' 表示本地货币符号。但它对 NULL 不友好——输入 NULL，返回 NULL，但不会报错，容易掩盖数据问题。
实操建议：
- 避免在 WHERE 或 JOIN 条件中用
FORMAT，比如WHERE FORMAT(price, 'N0') = '1,234'—— 这会强制全表转换，无法走索引 - 注意文化参数：不指定第三个参数时，默认用会话语言，
FORMAT(1234.5, 'C', 'de-DE')输出1.234,50 €，而'en-US'是$1,234.50 - 小数位截断不是四舍五入：
FORMAT(123.456, 'N2')→'123.46'（正常），但FORMAT(123.454, 'N2')→'123.45'（正确），它按 IEEE 规则处理，不是简单截断
SQL Server 中 FORMAT 日期的典型用法与陷阱
日期格式化比数字更易出错，因为格式字符串大小写敏感，'yyyy-MM-dd' 和 'YYYY-MM-DD' 效果完全不同（后者 Y 是“年份周期”，D 是“一年中的第几天”）。
实操建议：
- 年份必须用小写
yyyy，大写YYYY在某些文化下可能返回错误年份（比如周所属年） - 24 小时制用
HH（00–23），12 小时制用hh（01–12），混淆会导致时间显示异常，比如FORMAT(GETDATE(), 'yyyy-MM-dd hh:mm:ss')可能输出'2024-05-20 02:30:45'，你以为是下午，其实是凌晨 - 时区信息不会自动附加：即使传入
DATETIMEOFFSET，FORMAT默认输出不带偏移，要显式写'o'（Round-trip 格式）或拼接'zzz'
替代方案：更可靠、更通用的格式化思路
依赖 FORMAT 容易锁死在 SQL Server，一旦迁移或对接其他库就卡住。真正健壮的做法是把格式化逻辑上推到应用层，或用标准 SQL 函数兜底。
实操建议：
- SQL Server 中数字千分位：可用
CONVERT(varchar, CAST(x AS money), 1)，兼容性更好，性能更高 - 日期转
yyyy-MM-dd：用CONVERT(char(10), dt, 120)（120 是 ODBC 规范），比FORMAT(dt, 'yyyy-MM-dd')快 3–5 倍 - MySQL 对应：数字用
FORMAT(x, 2)（注意它四舍五入但不加货币符号），日期用DATE_FORMAT(dt, '%Y-%m-%d') - PostgreSQL 对应：数字用
TO_CHAR(x, 'FM999,999.00')，日期用TO_CHAR(dt, 'YYYY-MM-DD')
最常被忽略的一点：格式化函数几乎都不可 SARGable —— 意味着加了 FORMAT(created_at, 'yyyy-MM') 就没法利用 created_at 字段上的索引。真要按年月查，应该用 WHERE created_at >= '2024-05-01' AND created_at 。
