直接在WHERE中使用CAST会导致查询中断且无法定位错误行，必须改用TRY_CAST（SQL Server）或正则+TRIM组合（MySQL/PostgreSQL）先筛选NULL结果，再结合空值和不可见字符检查定位脏数据。

直接在 WHERE 里用 CAST 就会中断查询，你连哪一行出问题都看不到——必须换策略。

WHERE 中 CAST 失败导致整条语句报错

数据库执行 WHERE 时，只要某行 CAST 出错（比如 CAST('abc' AS INT)），整个查询立刻终止，不返回任何结果。这不是性能问题，是执行模型决定的：过滤阶段不容忍类型错误。

• 别写 WHERE CAST(price_str AS DECIMAL(10,2)) > 100 —— 一遇到非法值就炸
• 改用子查询或 CTE 先生成转换列，再加 IS NULL 判断
• MySQL/PostgreSQL 没有 TRY_CAST，得靠正则粗筛 + 显式空值检查

SQL Server 用 TRY_CAST 安全筛选失败行

TRY_CAST 不报错、只返 NULL，是定位脏数据的第一步。它不能代替校验，但能让你把“失败”变成可查的值。

• SELECT * FROM orders WHERE TRY_CAST(price_str AS DECIMAL(10,2)) IS NULL AND TRIM(price_str) != ''
• 注意：TRY_CAST('' AS INT) → NULL，TRY_CAST('1e4' AS INT) → NULL（科学计数法不被接受）
• 别和 ISNUMERIC() 混用：ISNUMERIC('') 返回 1，但 TRY_CAST('' AS INT) 仍是 NULL

MySQL/PostgreSQL 用正则+TRIM 手动兜底

这两个库没 TRY_CAST，只能靠模式匹配提前拦截明显非法值，再结合空格和不可见字符清理。

• MySQL：WHERE price_str NOT REGEXP '^[[:space:]]*[+-]?[0-9]*\.?[0-9]+([eE][+-]?[0-9]+)?[[:space:]]*$' OR TRIM(price_str) = ''
• PostgreSQL：WHERE price_str !~ '^ *[+-]?[0-9]*.?[0-9]+(e[+-]?[0-9]+)? *$' OR TRIM(price_str) = ''
• 特别注意 Unicode 零宽空格（U+200B）、制表符等不可见字符，TRIM() 默认不处理，需用 REGEXP_REPLACE(price_str, '[u200b ]', '') 清洗

日期类转换失败最常卡在格式和区域设置上

报错信息往往是“从字符串转换日期和/或时间时，转换失败”，但真正卡点不是数据本身，而是隐式解析规则。

• SQL Server：CAST('31/12/2023' AS DATE) 在默认 English 下失败（期待 MM/DD/YYYY），SET DATEFORMAT dmy 可解，但上线环境未必一致
• MySQL：CAST('2023-13-01' AS DATE) 静默返回 NULL，得配合 STR_TO_DATE(price_str, '%Y-%m-%d') 显式校验
• PostgreSQL：非 ISO 格式如 '01-12-2023' 直接报错，必须用 TO_DATE(col, 'DD-MM-YYYY')
• 带时区或毫秒的字符串（如 '2023-01-01T12:00:00.123Z'）多数库原生 CAST 不支持，得先清洗或用专用函数

复杂点在于：同一字段可能混着多种非法格式（空格、空字符串、科学计数法、零宽字符、错位日期），靠单条规则很难扫全。最稳的做法是先用宽松正则粗筛，再对候选行逐条人工确认原始值——比猜报错原因快得多。