日期字段类型不一致导致隐式转换失效，主因是date与datetime/timestamp或字符串混用；建议统一类型、避免字符串存日期、用范围匹配替代等值比较。
日期字段类型不一致导致隐式转换失效
最常见的原因是左表用 DATE，右表用 DATETIME 或 TIMESTAMP，或者一方是字符串（如 VARCHAR 存 '2024-01-01'）。数据库会尝试隐式转换，但索引通常失效，且比较逻辑可能出错——比如 '2024-01-01' 和 '2024-01-01 10:30:00' 在 = 下永远不等。
实操建议：
- 用
DESCRIBE table_name或\d table_name（PostgreSQL）确认两边日期字段的精确类型 - 避免用字符串存日期；若必须，统一转为
DATE再 JOIN：ON DATE(a.log_time) = b.date（注意：函数会导致索引失效） - 优先用类型一致的字段直接比较，例如都用
DATE(created_at)提前生成物化列或表达式索引
时间精度差异让相等判断失败
DATETIME 或 TIMESTAMP 字段常带毫秒、微秒，而 DATE 只保留年月日。直接写 a.created_at = b.date 几乎必然不成立，因为前者包含时分秒，后者被截断为 00:00:00。
实操建议：
- 用范围匹配替代等值：
ON a.created_at >= b.date AND a.created_at - 在 JOIN 前统一截断精度：
ON DATE(a.created_at) = b.date（适合小表；大表慎用，无索引） - PostgreSQL 可用
a.created_at::DATE = b.date，MySQL 用DATE(a.created_at) = b.date
LEFT JOIN 中日期条件写在 WHERE 而非 ON
想查“每天销售数据 + 当日所属活动”，但把活动时间范围条件放在 WHERE 里，结果没活动的日期直接消失——这不是匹配不到，是被过滤掉了。
实操建议：
- 时间范围筛选必须进
ON子句：LEFT JOIN promo p ON s.sale_date BETWEEN p.start_date AND p.end_date - 绝不能写成：
LEFT JOIN promo p ON s.sale_date = p.date WHERE p.start_date —— 这会让 LEFT JOIN 退化为 INNER JOIN - 如果需同时查“有活动的销售”和“无活动的销售”，保持
ON干净，用CASE WHEN p.id IS NULL THEN 'no_promo' ELSE p.name END区分
NULL 或时区未对齐干扰匹配
日期字段为 NULL 时，任何 =、BETWEEN 都返回 UNKNOWN，无法触发 JOIN；另外，跨时区写入的数据（如 UTC 存储但按本地时间查询）也会导致表面相同、实际错位。
实操建议：
- 先查空值比例：
SELECT COUNT(*), COUNT(date_col), COUNT(*) - COUNT(date_col) FROM table - 时区敏感场景，统一转换：
ON s.sale_time AT TIME ZONE 'UTC'::TIMESTAMP = p.effective_date（PostgreSQL） - 避免在
ON中用函数处理时区（如CONVERT_TZ()），否则索引失效；应在写入时归一化存储
日期字段 JOIN 不是“连不上”，而是“比得不对”。最易忽略的是：你以为在比日期，其实一半在比时间、一半在比字符串、一半在被 NULL 卡住。动手前先 SELECT 出两表的日期字段样本，用 pg_typeof() 或 DATA_TYPE 确认类型，再看是否有空、是否有毫秒、是否跨时区——这三步做完，80% 的“匹配不到”当场定位。
