mysql中cast有时不生效，因字符串含非数字前缀（如'abc456'→0）或空格导致静默截断；应先trim()再正则校验，避免误转。
CAST 在 MySQL 里为什么有时不生效？
因为字段本身是字符串，但内容像数字（比如 '123'），直接 CAST(col AS SIGNED) 看似合理，实际可能返回 0 或截断——MySQL 遇到开头非数字字符（如空格、'-' 后跟字母）就停住解析，不报错也不警告。
实操建议：
- 先用
TRIM()清掉首尾空格，再用REGEXP '^[+-]?[0-9]+(\.[0-9]+)?$'过滤非法值，避免静默转成0 -
CAST(' 456abc' AS SIGNED)→456，而CAST('abc456' AS SIGNED)→0，行为不一致，别依赖它做数据清洗 - 如果字段含单位（如
'2.5kg'），得先用REGEXP_SUBSTR(col, '^[+-]?[0-9]*\.?[0-9]+')提取数字部分，再 CAST
PostgreSQL 中 CAST 失败的典型错误信息
常见报错是：ERROR: invalid input syntax for type numeric 或 ERROR: cannot cast type text to integer。这不是语法错，而是运行时校验失败——PG 对类型转换更严格，不接受模糊匹配。
实操建议：
- 用
TRY_CAST？不行，PostgreSQL 没这个函数；改用NULLIF(col, '')::NUMERIC配合异常捕获逻辑（如外层加WHERE col ~ '^[+-]?[0-9]+(\.[0-9]+)?$'） -
CAST(col AS INTEGER)和col::INTEGER效果一样，但后者更短；不过在函数参数里（如sum(col::NUMERIC)）推荐用双冒号，可读性略高 - 小数点后位数超长（如
'123.456789012345'转NUMERIC(5,2)）会直接报错，不是四舍五入，得提前用ROUND()或改目标精度
SQL Server 里 CAST 和 CONVERT 的关键区别
CAST 是 ANSI 标准，写法统一但功能少；CONVERT 是 SQL Server 扩展，支持格式化（比如日期转字符串），也支持显式样式码，但可移植性差。
实操建议：
- 纯类型转换（如
varchar→int）优先用CAST，语义清晰；需要格式控制（如把datetime转成'yyyy-mm-dd'）必须用CONVERT，并指定第三个参数（如CONVERT(VARCHAR, getdate(), 23)） -
CAST('123.45' AS INT)在 SQL Server 里会截断（→123），不四舍五入；要四舍五入得先ROUND()再 CAST - 从
float转decimal容易丢精度，比如CAST(123.456789 AS DECIMAL(10,2))可能变成123.46或123.45，取决于底层二进制表示，别假设它“精确”
跨数据库迁移时 CAST 的兼容性陷阱
同一个 CAST(col AS BIGINT) 在 MySQL、PostgreSQL、SQL Server 上表现可能不同：MySQL 允许前导空格，PG 不允许，SQL Server 对溢出处理方式也不同（溢出时 MySQL 返回 NULL，PG 报错，SQL Server 可能截断或报错）。
实操建议：
- 不要在应用逻辑里硬写数据库专属 CAST；把类型转换逻辑下沉到视图或中间层，用条件判断屏蔽差异
- 测试时重点覆盖边界值：空字符串、
NULL、超长数字、科学计数法（如'1e5'）、带千分位符（如'1,234'）——这些在各库中几乎都不被 CAST 原生支持 - 如果字段本意就是数值，建表时就该用正确类型；临时 CAST 是补救手段，不是设计选择
类型转换看着简单，真正麻烦的是那些没报错却悄悄变了的数据——比如 ' 7' 和 '7 ' 在某些库中 CAST 结果一样，但在另一些库里一个成功一个变 0。验证不能只看“有没有报错”，得查具体值。
