优先用convert，性能高且兼容性好；format仅适用于展示层，因性能差且导致索引失效。
直接用 FORMAT() 就行，但得注意它只在 SQL Server 2012+ 可用，且性能比 CONVERT() 差不少——尤其查百万行以上时，别让它出现在 WHERE 或 JOIN 条件里。
FORMAT() 的基本调用和 format_string 规则
FORMAT() 的第二个参数是 .NET 风格的格式字符串，不是 SQL Server 自己那套数字 style 编码。比如 'yyyy-MM-dd'、'MM/dd/yyyy'、'dddd, MMMM dd, yyyy' 都合法；大小写敏感，'YYYY' 会输出字面量 Y，必须用 'yyyy' 才是年份。
-
'yyyy'：4 位年（2026），'yy'：2 位（26） -
'MM'：补零月（06），'M'：不补零（6） -
'dd'：补零日，'d'：不补零；'HH'是 24 小时制，'hh'是 12 小时制 - 分隔符如
@、年、月等可直接写进字符串，比如'yyyy年MM月dd日' - 中文星期/月份名依赖
culture参数，例如FORMAT(GETDATE(), 'dddd', 'zh-CN')输出“星期日”
为什么 FORMAT() 在大数据量查询中容易拖慢性能
FORMAT() 是 CLR 函数，每次调用都要跨 T-SQL 和 .NET 边界，且无法利用索引——哪怕你对 OrderDate 建了索引，WHERE FORMAT(OrderDate, 'yyyy-MM') = '2026-06' 也会全表扫描。
- 替代方案：用
CONVERT(VARCHAR(7), OrderDate, 120)拿'2026-06'，或用YEAR(OrderDate) = 2026 AND MONTH(OrderDate) = 6 - 如果必须用
FORMAT()做展示层输出，确保它只出现在 SELECT 列表末尾，不在过滤、分组、排序逻辑里 - 执行计划里看到
Compute Scalar节点频繁出现，大概率就是它在拖后腿
常见错误：culture 参数填错或漏掉导致结果异常
省略 culture 时，默认用当前会话的 LANGUAGE 设置，而这个设置可能被显式改过（比如 SET LANGUAGE 'British'），导致 FORMAT(GETDATE(), 'dddd') 输出 “Saturday” 而非 “星期日”。
- 要稳定输出中文，显式传
'zh-CN'：FORMAT(GETDATE(), 'yyyy年MM月dd日', 'zh-CN') -
'en-US'下'MM/dd/yyyy'是默认，'de-DE'下就变成'dd.MM.yyyy' - 传入非法 culture 名（如
'zh'而非'zh-CN'）会报错：Msg 9815, Level 16, State 1, Line X: The culture parameter is not valid. - 服务器未启用 CLR 时，
FORMAT()会直接不可用（不过 SQL Server 2019 默认已启用）
真正麻烦的不是语法怎么写，而是忘了它本质是个“展示层函数”——把它当过滤条件用，或者在视图/函数里无节制封装，后面查数据越来越慢时，很难一眼定位到根因。
