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