cast是标准sql跨数据库通用函数，语法为cast(表达式 as 目标类型)，不支持格式化且失败报错；convert是sql server特有函数，支持样式码实现日期数字格式化，但不可移植。
优先用 CAST，只在 SQL Server 里需要格式化日期/数字时才用 CONVERT；硬转失败会中断查询，得用 TRY_CAST 或预处理兜底。
CAST 和 CONVERT 的语法别写反
CAST 必须带 AS，顺序固定：CAST(expression AS data_type)。漏掉 AS 或把类型放前面（比如写成 CAST(INT AS col)）直接报错。CONVERT 是函数式调用，目标类型在前：CONVERT(data_type, expression[, style])。常见错误是把参数颠倒，比如 CONVERT('123', INT) —— SQL Server 报 Incorrect syntax near ','。
字符串转数值或日期时，长度要显式写括号：CAST(name AS VARCHAR(50))、CONVERT(VARCHAR(50), name)。不写默认按 30 截断，容易丢数据。
字符串转数字失败的典型原因和应对
报错 Conversion failed when converting the varchar value 'abc' to data type int，不是函数问题，而是源字段含空格、空字符串或非数字字符。
-
CAST('' AS INT)和CAST(' ' AS INT)在 SQL Server 中都失败，得先清理：NULLIF(TRIM(col), '')再套CAST -
CAST('12.5' AS INT)失败，因为INT不接受小数位；该用DECIMAL(9,2)，或先ROUND() - 想“安全转换”就别硬扛：
TRY_CAST('12.5' AS INT)失败返回NULL，不中断执行（SQL Server / PostgreSQL 支持；MySQL 用SAFE_CAST需查版本）
日期字符串转换为什么总出错
核心是区域设置依赖：CONVERT(DATE, '01/02/2023') 在 US 设置下是 1 月 2 日，在 UK 下是 2 月 1 日；CAST 同样不稳定。
可靠做法只有两个：
- 统一用 ISO 格式：
CAST('2023-02-01' AS DATE)，完全不受语言/地区影响 - 显式指定
style：CONVERT(DATE, '01/02/2023', 101)（101 = mm/dd/yyyy），103= dd/mm/yyyy，112= yyyymmdd - 避免
CAST(CONVERT(VARCHAR, GETDATE(), 101) AS DATE)这种嵌套——多一层隐式转换，还可能因当前会话设置失效
WHERE 条件里用 CAST 的性能陷阱
在 WHERE 子句中对列用 CAST(col AS VARCHAR) 或 CONVERT(VARCHAR, col)，会导致索引失效，全表扫描。
更糟的是隐式转换：比如 WHERE date_col = '2023-10-05'，如果 date_col 是 DATETIME，SQL Server 可能自动转成 CAST('2023-10-05' AS DATETIME)，但精度丢失（时间部分被补 00:00:00），且仍可能跳过索引。
真正安全又高效的做法：
- 让参数类型匹配列类型，而不是反过来转列
- 日期比较用范围：
WHERE date_col >= '2023-10-05' AND date_col - 字符串比较前确认 collation 兼容，避免隐式转换触发全表扫描
最常被忽略的一点：style 参数只对 DATE/DATETIME→VARCHAR 或 MONEY→VARCHAR 生效，传给 INT→VARCHAR 会被忽略，但很多人误以为它能控制数字千分位——那得用 FORMAT()（性能差）或应用层处理。
