to_date函数默认仅支持'yyyy-mm-dd'格式，解析非标准格式需显式指定格式字符串，且对大小写、年份位数、分隔符敏感；输入含空格或非法字符会导致null；分区字段上使用会引发裁剪失效。
TO_DATE函数在Spark SQL里到底支持哪些日期格式
Spark SQL的TO_DATE函数默认只识别'yyyy-MM-dd'这种标准格式，比如'2023-12-25'能直接转，但'25/12/2023'或'20231225'会返回NULL——不是函数坏了，是它没配格式模板。
必须显式传入第二个参数（格式字符串）才能解析非标准文本：
SELECT TO_DATE('25/12/2023', 'dd/MM/yyyy') AS parsed_date;
- 格式符大小写敏感：
'MM'是月份，'mm'是分钟，写错就全错 - 年份用
'yyyy'，不能用'yy'（后者会被当成两位年，2023→20，结果变成2000年） - 中文分隔符（如“年”“月”“日”）不被支持，必须用英文符号或数字
为什么用了正确格式还是返回NULL
常见原因不是格式写错了，而是输入值本身含不可见字符或空格。比如字段里实际是' 2023-01-01 '（首尾有空格），或者从CSV读进来带BOM头、制表符等。
排查和修复建议：
- 先用
TRIM()清洗：TO_DATE(TRIM(date_str), 'yyyy-MM-dd') - 检查是否有非法字符：
SELECT date_str, LENGTH(date_str), ASCII(SUBSTR(date_str, 1, 1)) FROM t LIMIT 5 - 如果数据混杂多种格式（如部分是
yyyy-MM-dd，部分是yyyyMMdd），TO_DATE无法自动适配，得用CASE WHEN分支处理
替代方案：当TO_DATE不够用时该选哪个函数
如果要兼容模糊输入、容忍缺失位数（如'2023-1-5'）、或需要更灵活解析，TO_DATE就力不从心了。这时可考虑：
-
TRY_TO_DATE()（Databricks Runtime 11.3+ 或 Spark 3.4+）：不会报错，解析失败时返回NULL，比TO_DATE更安全 -
UNIX_TIMESTAMP() + FROM_UNIXTIME()组合：适合已知固定格式但需做时区转换的场景 - UDF（自定义函数）：极端情况（如解析“去年12月第3个周一”这类语义日期），但会损失SQL优化能力，慎用
注意：TO_DATE返回的是DATE类型，不含时间；如果原始文本含时间（如'2023-01-01 10:30:00'），必须用TO_TIMESTAMP，否则时间部分被截断且无警告。
分区字段用TO_DATE时容易忽略的性能陷阱
在WHERE条件里对分区字段（比如dt STRING）反复调用TO_DATE(dt, 'yyyyMMdd')，会导致分区裁剪失效——Spark无法推断出哪个分区目录要扫描，可能全表扫描。
正确做法：
- 提前把分区字段转成
DATE类型并重命名（如dt_date），让分区列本身就是标准日期 - 如果必须用字符串分区，WHERE里改用字符串比较：
WHERE dt BETWEEN '20230101' AND '20231231'，避免函数包裹 - 建表时直接定义分区列为
DATE类型（Spark 3.0+ 支持），后续所有操作天然适配
日期解析看着简单，但格式、空格、分区、类型这几个点一碰就卡住，尤其跨系统迁移数据时，原始格式往往比文档写的更野。
