CAST需指定目标类型长度（如VARCHAR(20)），浮点数转字符串易出科学计数法，应先ROUND；显式CAST比隐式转换更安全可控，跨库需注意类型名差异。
CAST 函数怎么写才不会报错
SQL 里用 CAST 转数值为字符串，最常见错误是漏写目标类型或写错格式。比如 CAST(price AS VARCHAR) 在 PostgreSQL 里会失败——VARCHAR 必须带长度，得写成 CAST(price AS VARCHAR(20))；而 SQL Server 允许 VARCHAR 不带长度，但实际分配默认长度（通常是 30），可能截断长数字。
-
CAST(123.45 AS CHAR)在 MySQL 中会报错，必须指定长度：CAST(123.45 AS CHAR(10)) - PostgreSQL 对
TEXT更友好：CAST(123.45 AS TEXT)安全、无需长度 - Oracle 不支持
TEXT，得用CAST(123.45 AS VARCHAR2(20)) - 整数转字符串时，
CAST(id AS VARCHAR(10))比CAST(id AS CHAR(10))更稳妥，后者会补空格，影响后续拼接或比较
为什么有时候 CAST 出来是科学计数法
浮点数（如 REAL、DOUBLE PRECISION）用 CAST 直接转字符串，数据库可能自动用科学计数法表示，比如 CAST(123456789.123 AS VARCHAR(20)) 得到 '1.23456789123e+08'。这不是 bug，是多数数据库对浮点精度的默认行为。
- 想避免科学计数法，先用
ROUND或TRUNC控制小数位：CAST(ROUND(amount, 2) AS VARCHAR(20)) - PostgreSQL 可改用
TO_CHAR(amount, 'FM999999990.00')，但这是函数而非CAST，不属于本题范围 - MySQL 8.0+ 支持
FORMAT()，但会加千分位，不适合纯字符串转换场景 - 如果字段本身就是
DECIMAL或NUMERIC，一般不会触发科学计数法，优先确保源类型精确
CAST 和隐式转换比，哪个更安全
显式用 CAST 比依赖数据库自动隐式转换更可控。比如在 WHERE name = 123 这种混用中，MySQL 可能悄悄把 name 转成数字去比，结果全表扫描还漏数据；而 WHERE name = CAST(123 AS CHAR) 至少明确表达了意图，也更容易被索引利用（取决于字段类型和 collation）。
- 隐式转换在 JOIN 条件里风险最高：一边是
INT，一边是VARCHAR，数据库可能放弃索引走全表 -
CAST的执行计划通常更可预测，尤其在 WHERE 或 ORDER BY 中参与排序时 - 某些数据库（如 SQL Server）对隐式转换有警告日志，但生产环境未必开启，靠
CAST是主动防御 - 注意：
CAST(NULL AS VARCHAR(10))结果仍是NULL，不是空字符串，别误以为能“兜底”
不同数据库对 CAST 的兼容性差异
同一句 CAST 在不同库跑不通，往往不是语法错，而是类型名或行为不一致。比如 VARCHAR 在各库含义不同，CHAR 的填充规则也不同。
- PostgreSQL 接受
TEXT，MySQL 5.7 不接受，8.0+ 才支持作为目标类型 - SQL Server 的
CAST(123 AS VARCHAR)等价于VARCHAR(30)，但 Oracle 会直接报错：“type not found” - SQLite 把
CAST(x AS TEXT)当作强制字符串化，行为最宽松，但不保证格式（如负号位置、小数点后零） - 跨库迁移时，若需最大兼容，优先选
CAST(col AS VARCHAR(50))并测试边界值（如-999999999999.999）
真正麻烦的不是写法，是数值本身含不可见字符（比如从 ETL 导入的带 BOM 的 CSV）、或存在 NaN/Infinity 这类特殊浮点值——这些在 CAST 前就得清理掉，否则任何数据库都会报错或静默失败。
