CAST用错类型会直接报错而非静默截断，关键看目标类型能否容纳原始数据；数字转换需防精度丢失与溢出，隐式转换易致索引失效，应保持比较类型一致并启用严格模式，必要时用TRY_CAST等安全函数。
CAST 用错类型会直接报错，不是静默截断
SQL 里 CAST 不是万能兜底工具。比如把超长字符串转 CHAR(5)，PostgreSQL 会抛 value too long for type character(5)，MySQL 可能截断但带 warning，SQL Server 则默认报错。关键不是“能不能转”，而是“目标类型是否容纳得下原始数据”。
- 先查源字段最大长度：
SELECT MAX(LENGTH(col_name)) FROM table_name - 目标类型长度至少比最大值多 1–2 字节（留空格或符号位）
- 数字类型更要小心：把
DECIMAL(10,2)转成INT，小数部分直接丢，且超出INT范围（±2147483647）就报错 - PostgreSQL 中
CAST('123.45' AS INTEGER)直接失败，必须先ROUND或TRUNC
隐式转换在 WHERE 条件里悄悄拖慢查询
写 WHERE int_col = '123' 看似没问题，但数据库可能对 int_col 每行都做 CAST，导致索引失效。尤其在大表上，执行计划里出现 Seq Scan 或 Index Cond: (int_col = ('123')::integer) 就是危险信号。
- 始终让比较双方类型一致：数字用数字，字符串用字符串
- 参数化查询时，应用层传入的值类型要和字段匹配，别依赖驱动自动转换
- MySQL 8.0+ 对
VARCHAR和TEXT的隐式转换更严格，WHERE text_col = 123可能全表扫描 + 类型警告 - SQL Server 中
WHERE date_col = '2023-01-01'是安全的，但WHERE date_col = '01/01/2023'可能触发语言设置依赖，建议统一用 ISO 格式'2023-01-01'
溢出不报错？那是你没开严格模式
MySQL 默认的 sql_mode 不含 STRICT_TRANS_TABLES，导致 INSERT INTO t(c1) VALUES(CAST('999999999999' AS TINYINT)) 不报错，而是存成 127（TINYINT 最大值）。这种“静默溢出”比报错更危险——数据错了还察觉不到。
- 开发/测试环境务必启用严格模式：
SET sql_mode = 'STRICT_TRANS_TABLES'; - PostgreSQL 没这类妥协，默认所有溢出都报错，但要注意
NUMERIC精度丢失（如CAST(123.456 AS NUMERIC(3,1))→123.5，四舍五入而非截断） - SQL Server 的
ARITHABORT和ANSI_WARNINGS也影响溢出行为，批量导入时建议显式设为ON
用 TRY_CAST（SQL Server）或 SAFE_CAST（BigQuery）代替 CAST
当无法确保输入干净，又不想整个语句崩掉时，传统 CAST 太硬。SQL Server 的 TRY_CAST、BigQuery 的 SAFE_CAST 在失败时返回 NULL 而非报错，适合清洗中间表或 ETL 场景。
-
SELECT TRY_CAST(maybe_number AS INT) AS safe_int FROM log_table—— 错误值变NULL，不影响整行输出 - 但注意：返回
NULL后，后续计算（如SUM）会忽略它，可能掩盖数据质量问题 - PostgreSQL 没原生
SAFE_CAST，常用NULLIF+ 正则预判：NULLIF(col, '') ~ '^\d+$' THEN col::INT ELSE NULL END - 这些函数不走索引，别在
WHERE里滥用，否则扫全表
类型转换最麻烦的从来不是语法，而是上下游系统对“合法值”的定义不一致——比如前端传 "123.00"，后端解析成 float，再进 DB 却要求精确到分的 DECIMAL(10,2)。这时候光靠 CAST 解决不了，得在接口层卡住格式，或者加 CHECK 约束兜底。
