sql server 2008 r2等低版本不支持try_parse，需用isdate()结合convert并额外校验日期有效性；try_parse因静默返回null、支持culture指定和模糊格式解析而更安全，但需显式指定using且须配合数据清洗。
SQL Server里没有PARSE或TRY_PARSE时怎么办
SQL Server 2012+ 才支持 TRY_PARSE，低版本（如2008 R2）直接报错 Invalid object name 'TRY_PARSE'。别硬套函数——先确认版本：SELECT @@VERSION。若不支持，得用 ISDATE() + CONVERT 组合兜底，但注意 ISDATE('2023-02-30') 返回 1，而 CONVERT(DATE, '2023-02-30') 会炸，所以不能只信 ISDATE。
TRY_PARSE比CONVERT安全在哪
TRY_PARSE 在解析失败时不抛异常，而是返回 NULL，适合处理混杂格式的字段（比如用户输入的 '2023/04/01'、'01-Apr-2023'、'20230401'）。它还能指定文化（culture），比如 TRY_PARSE('15.03.2023' AS DATE USING 'de-DE') 能正确识别德式分隔符；而 CONVERT 对非标准格式基本无能为力，强行转会报 Conversion failed when converting date and/or time from character string。
-
TRY_PARSE支持模糊格式推断，CONVERT要求格式严格匹配 style 参数 - 当列中存在空格、多余标点（如
'[2023-05-20]'）时，TRY_PARSE仍可能成功，CONVERT几乎必败 -
TRY_PARSE性能略低，大量数据时建议先用LEN或LIKE粗筛再调用
PARSE和TRY_PARSE的核心区别
PARSE 和 TRY_PARSE 参数完全一致，唯一差别是错误处理：前者失败直接中断查询并报错；后者静默返回 NULL。线上环境必须用 TRY_PARSE，尤其在 ETL 或报表取数场景下，一条脏数据不该拖垮整批结果。
- 语法都是：
TRY_PARSE(@input AS DATE USING 'en-US') -
USING子句不是可选——省略时依赖当前会话 culture，生产环境务必显式指定 - 不支持自定义格式字符串（如
'yyyy-MM-dd'），那是FORMAT的事，且FORMAT是单向的，不能反向解析
真正安全的解析还得加一层清洗
即使用了 TRY_PARSE，遇到 '2023-13-01'、'abc'、''、NULL 都会返回 NULL，但这不代表业务上就合理。例如订单时间不能早于系统上线日，就得额外校验：
SELECT
TRY_PARSE(cleaned_date AS DATE USING 'en-US') AS parsed_date,
CASE
WHEN TRY_PARSE(cleaned_date AS DATE USING 'en-US')
<p>真正容易被忽略的是不可见字符（制表符、换行符、零宽空格）和区域设置漂移——同一段 SQL 在不同服务器上因默认 culture 不同，<code>TRY_PARSE('05/06/2023' AS DATE)</code> 可能被当成 5月6日 或 6月5日。显式写死 <code>USING</code> 不是多此一举，是必须动作。</p>
