CAST是跨库兼容的类型转换标准函数，语法为CAST(expr AS type)，但各数据库对目标类型名、长度要求及错误处理不同：MySQL用SIGNED/UNSIGNED而非INT，PostgreSQL要求VARCHAR带长度，SQL Server对非法字符串转数字直接报错，而MySQL静默返回0。
CAST 能强制转换字段类型，但不是所有数据库都支持相同语法，用错会直接报错。
CAST 在不同数据库里的写法差异
MySQL、PostgreSQL、SQL Server 都支持 CAST()，但 SQLite 只支持 CAST()（不支持 CONVERT()），而 Oracle 偏好 TO_NUMBER() 等函数。别照搬别人代码里的写法。
- 标准写法：
CAST(column_name AS target_type)，比如CAST(age AS VARCHAR) - PostgreSQL 要求指定长度：
CAST(price AS DECIMAL(10,2))，否则可能截断或报错 - MySQL 对
VARCHAR类型可省略长度，但生产环境建议写全：CAST(name AS CHAR(50)) - SQL Server 中
CAST('2023-01-01' AS DATE)成功，但若字符串格式非法（如'2023/13/01'）会直接中断查询
SELECT 中 CAST 字段的常见错误
最常踩的坑是类型不兼容或隐式转换干扰结果——CAST 不是万能兜底，它只按你写的规则硬转。
- 把含字母的字符串转数字：
CAST('abc' AS INT)→ 在 SQL Server 报Conversion failed，在 MySQL 返回 0（静默失败，极难排查） - 日期字符串格式不匹配：
CAST('01-01-2023' AS DATE)在 PostgreSQL 可能被当成 MDY 或 DMY，取决于datestyle设置 - 对 NULL 值 CAST 没问题，但后续参与计算时要注意：例如
CAST(NULL AS INT) + 5结果仍是NULL，不是 5 - 别在 WHERE 条件里对字段 CAST 后再比较，比如
WHERE CAST(created_at AS DATE) = '2023-01-01'，会跳过索引，改用created_at >= '2023-01-01' AND created_at
什么时候该用 CAST，什么时候该避免
核心判断依据是：是否真的需要改变数据物理表示，还是仅需格式化展示？后者优先用数据库特有函数（如 TO_CHAR()、DATE_FORMAT()）。
- 必须用 CAST 的场景：拼接不同类型的字段，如
SELECT CAST(id AS VARCHAR) + '_item' FROM products（SQL Server） - 导出前统一类型：导 Excel 时把
DECIMAL转VARCHAR防止科学计数法显示 - 联表时类型不一致：A 表
user_id是VARCHAR，B 表是INT，JOIN 前用CAST对齐（但更优解是修复建表类型） - 避免滥用：SELECT 列里大量 CAST 会影响执行计划，尤其在视图或子查询中嵌套多层 CAST，会让优化器“看不懂”实际数据分布
真正麻烦的不是语法写不对，而是 CAST 后的数据行为和原类型不一致——比如时区丢失、精度截断、排序顺序突变。上线前务必用真实数据测边界值，别只看 '123' 这种理想输入。
