CAST('03/08/2026' AS DATE)在不同数据库表现不一致，因各库默认解析规则不同：SQL Server按MDY解析为3月8日，PostgreSQL受datestyle影响可能报错或误判，MySQL对非法日期静默返回NULL；唯一安全写法是ISO格式CAST('2026-08-03' AS DATE)。
CAST('03/08/2026' AS DATE) 为什么在不同库表现不一致
不是语法错了，是日期字符串格式和数据库默认解析规则不匹配。SQL Server 默认按 MDY（月/日/年）解析，'03/08/2026' 被当成 3月8日；PostgreSQL 默认 YMD，但受 datestyle 设置影响，可能直接报错；MySQL 更倾向宽松处理，但遇到 '31/02/2026' 这类非法日期会静默返回 NULL，而不是报错。
真正安全的写法只有一种：CAST('2026-08-03' AS DATE)——所有主流数据库都认 ISO 格式。其他格式必须提前清洗或用专用函数替代。
- 别依赖 CAST 猜格式，它不做格式协商，只做硬映射
- 带分隔符但非 ISO 的字符串（如
'08.03.2026'、'03-08-2026'）几乎必然失败 - SQL Server 可用
CONVERT(DATE, '03/08/2026', 103)强制按 DD/MM/YYYY 解析，但该写法不可跨库
CAST('2026-13-01' AS DATE) 不报错却返回 NULL，怎么发现
MySQL 和 PostgreSQL 对非法日期不抛错，而是返回 NULL，这比报错更危险——你查不到错误，只能看到结果“少数据”。SQL Server 则直接中断查询，报 Msg 241。
定位方式不是靠 CAST 本身，而是靠前置过滤：
- MySQL：
WHERE col NOT REGEXP '^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$'先筛出合法格式 - PostgreSQL：
WHERE col ~ '^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12][0-9]|3[01])$' - SQL Server：用
TRY_CAST(col AS DATE) IS NULL AND col IS NOT NULL找出转换失败行
注意：空格、不可见字符（如 U+0000）、全角数字也会导致失败，建议先 TRIM(col) 再校验。
为什么 WHERE CAST(created_at AS DATE) = '2026-08-03' 查不出数据
表里明明有 '2026-08-03 14:22:05'，但这条语句查不到，不是因为 CAST 写错了，而是索引失效 + 类型隐式转换双重干扰。
CAST(created_at AS DATE) 是计算列，数据库无法利用 created_at 上的索引，只能全表扫描。更麻烦的是，如果 created_at 是 VARCHAR 类型，CAST 还要先做字符串解析，失败就整行跳过或报错。
- 正确写法是范围查询：
WHERE created_at >= '2026-08-03' AND created_at - 若字段确实是字符串且需高频按日期查，建生成列：
ALTER TABLE t ADD created_date DATE GENERATED ALWAYS AS (CAST(created_at AS DATE)) STORED，再对created_date建索引 - 避免在 WHERE 中嵌套任何转换函数，尤其是日期类
带时区或毫秒的字符串能用 CAST 直接转吗
不能。'2026-08-03T12:00:00.123Z'、'2026-08-03 12:00:00+08' 这类字符串，所有主流数据库的原生 CAST 都不支持。
它们不是“格式不对”，而是超出了 CAST 的能力边界——CAST 只做类型映射，不做解析归一化。
- SQL Server：用
TRY_CONVERT(datetimeoffset, col)或PARSE(col AS datetime2 USING 'en-US') - PostgreSQL：用
TO_TIMESTAMP(col, 'YYYY-MM-DD"T"HH24:MI:SS.US"Z"')，注意模板必须严格匹配 - MySQL：用
STR_TO_DATE(col, '%Y-%m-%dT%h:%i:%s.%fZ')，但需确认版本是否支持微秒
最稳妥的做法是：入库前清洗成标准 ISO 日期时间字符串，而不是指望查询时靠 CAST 补救。
