优先用CAST确保跨库兼容性；CONVERT仅限SQL Server且需格式控制；语法顺序、括号长度、脏数据处理、ISO日期、索引失效及源头清洗是关键要点。
别直接套 CAST 或 CONVERT，先看环境——跨数据库或未来可能迁移，必须用 CAST；纯 SQL Server 且要控制日期/数字输出格式，才考虑 CONVERT。
CAST 和 CONVERT 的语法差异必须写对
写反参数顺序或漏关键字是高频报错原因。
-
CAST只有一种写法：CAST(expression AS data_type)，AS不可省，data_type在后；写成CAST(INT AS col)或CAST(col TO INT)都会报错 -
CONVERT是函数式调用：CONVERT(data_type, expression[, style])，目标类型在前；写成CONVERT('2023-01-01', DATE)直接触发Incorrect syntax near ',' - 指定长度时都得带括号：
CAST(name AS VARCHAR(100))，不写默认按 30 截断，容易丢数据
字符串转数字失败，90% 是脏数据惹的祸
报错 Conversion failed when converting the varchar value 'N/A' to data type int 不是函数问题，是源字段含非数字内容。
-
CAST('' AS INT)和CAST(' ' AS INT)在 SQL Server 中直接失败；得先NULLIF(TRIM(col), '')再套CAST - MySQL 对
CONVERT('123abc', SIGNED)会静默取前缀123，但CONVERT('abc123', SIGNED)返回0，行为不可靠 - 安全做法：SQL Server 用
TRY_CAST(col AS INT)（失败返回NULL）；MySQL 用正则预过滤：CAST(IF(col REGEXP '^[0-9]+(\.[0-9]+)?$', col, NULL) AS DECIMAL(10,2))
日期字符串转换最危险，ISO 格式是唯一共识
CAST('01/02/2023' AS DATE) 在 US 设置下是 1 月 2 日，在 UK 下是 2 月 1 日——区域依赖导致结果不可控。
- 唯一可靠写法：
CAST('2023-02-01' AS DATE)，所有主流数据库都按 ISO 8601 解析，无歧义 - 若必须处理非 ISO 字符串，SQL Server 可用
CONVERT(DATE, '01/02/2023', 101)（101 = mm/dd/yyyy），但换到 PostgreSQL 就失效 - 避免嵌套转换：
CAST(CONVERT(VARCHAR, GETDATE(), 101) AS DATE)多此一举，还引入隐式转换风险
WHERE 条件里用 CAST/CONVERT 会让索引失效
写成 WHERE CAST(order_no AS INT) > 1000，哪怕 order_no 字段上有索引，也会强制全表扫描。
- 优化方向不是改函数，而是调整比较逻辑：
WHERE order_no > '1000'（前提是字符串能字典序比大小） - 更彻底的解法：建计算列并索引，比如
ALTER TABLE orders ADD order_no_int AS TRY_CAST(order_no AS INT)，再在该列建索引 - 聚合或 JOIN 前就该清洗类型，别把转换压力堆在查询层；临时硬套
CAST很快会暴露性能瓶颈
真正难处理的从来不是语法，而是嵌套条件里混着多种类型、又没统一清洗的数据源——这时候光靠 CAST 或 CONVERT 挡不住问题，得回溯源头改结构或加约束。
