convert函数仅sql server/sybase原生支持，非跨库通用；其必需三参数为target_type、expression、style，漏写style将触发隐式转换致格式异常，如convert(varchar, getdate())默认按style=0输出mon dd yyyy hh:miam。
CONVERT 函数不是跨数据库通用的日期格式化方案，它只在 SQL Server 和 Sybase 中原生支持；MySQL 用 DATE_FORMAT，PostgreSQL 用 TO_CHAR，SQLite 用 strftime —— 直接套用会报错。
SQL Server 中 CONVERT 的三个必需参数
CONVERT 在 SQL Server 里必须传三个参数：目标数据类型、源表达式、样式编号（style）。漏掉第三个参数或传错类型，结果可能出人意料。
- 目标类型常用
CHAR、VARCHAR、NVARCHAR（不能写STRING或TEXT） - 源表达式可以是列名（如
OrderDate）、字面量（如'2023-12-25'）或函数返回值（如GETDATE()） - 样式编号决定格式，比如
103是dd/mm/yyyy，120是yyyy-mm-dd hh:mi:ss（ODBC 规范），126支持毫秒和时区（ISO 8601） - 不指定样式编号（即只传两个参数）会触发隐式转换，可能丢失时间部分或返回意外格式，例如
CONVERT(VARCHAR, GETDATE())默认按style=0输出mon dd yyyy hh:miAM
常见样式编号与对应输出（SQL Server）
样式编号不是“越小越好”或“越大越全”，选错会导致截断、乱序甚至报错。比如 style=101（mm/dd/yyyy）在英国环境可能引发业务误解；style=130（伊斯兰历）需要服务器语言支持，否则报错。
-
101→05/23/2024（美国习惯） -
103→23/05/2024（英国/印度等） -
120→2024-05-23 14:30:22（无毫秒，可排序） -
126→2024-05-23T14:30:22.123（带毫秒，ISO 标准，推荐用于 API 交互） -
131→22/09/1445 2:30:22:123PM（仅当SET LANGUAGE 'Arabic'时有效）
CONVERT vs CAST：什么时候该换用 CAST？
如果只是类型转换（比如 DATETIME → DATE），不用格式化，CAST 更简洁、更标准、兼容性更好。而 CONVERT 唯一不可替代的场景是依赖样式编号做格式控制。
-
CAST(OrderDate AS DATE)安全、可移植，且明确丢弃时间部分 -
CONVERT(VARCHAR, OrderDate, 103)只为生成dd/mm/yyyy字符串，不能反向解析回日期（除非再用CONVERT(DATE, ..., 103)） - 用
CONVERT转成字符串后参与比较（如WHERE CONVERT(VARCHAR, dt, 103) = '23/05/2024'）会强制索引失效，性能极差 - 若需兼顾格式和可索引性，应改用计算列 + 索引，或在应用层格式化
样式编号的语义高度依赖 SQL Server 版本和 SET LANGUAGE 设置，同一编号在不同会话中可能输出不同分隔符或星期名称；生产环境若需稳定输出，建议显式拼接（如 CONVERT(CHAR(4), YEAR(dt)) + '-' + RIGHT('0' + CONVERT(CHAR(2), MONTH(dt)), 2) + '-...）或统一使用 FORMAT 函数（SQL Server 2012+，但性能更差）。
