MySQL中DATE()函数在JOIN的ON条件中会导致索引失效，应改用范围查询+子查询/CTE：先WHERE b.ts >= '2026-08-12' AND b.ts

MySQL中用DATE()函数截断时间戳再JOIN

直接在ON条件里对时间字段做函数运算（比如DATE(a.ts) = DATE(b.ts)）会导致索引失效，哪怕两边都有ts字段的B+树索引，优化器也会放弃使用，转为全表扫描。

正确做法是先用范围条件缩小右表候选集，再在子查询或CTE里做日期截断：

• 确保b.ts上有索引：CREATE INDEX idx_b_ts ON b(ts);
• 用WHERE b.ts >= '2026-08-12' AND b.ts 替代<code>DATE(b.ts) = '2026-08-12'
• 若必须用DATE()，只在SELECT列表或WHERE中用于已过滤后的结果，绝不放在JOIN条件里

PostgreSQL里用CAST(ts AS DATE)配合B-tree索引

PostgreSQL对CAST(ts AS DATE)的支持比MySQL更友好，但依然不能直接在JOIN的ON里写CAST(a.ts AS DATE) = CAST(b.ts AS DATE)——这仍会阻止索引下推。

推荐组合方式：

• 给b.ts建表达式索引：CREATE INDEX idx_b_ts_date ON b((ts::DATE));
• JOIN时显式使用该表达式：ON (a.ts::DATE) = (b.ts::DATE)
• 注意：表达式索引只对完全匹配该表达式的查询生效，DATE(b.ts)或CAST(b.ts AS DATE)都行，但TO_CHAR(b.ts, 'YYYY-MM-DD')不行

SQL Server中避免在ON里用CONVERT(DATE, ...)

SQL Server虽然支持CONVERT(DATE, GETDATE())，但在JOIN条件中写CONVERT(DATE, a.ts) = CONVERT(DATE, b.ts)会让执行计划跳过索引查找，降级为嵌套循环+全表扫描。

更安全的写法是用范围谓词代替：

• 把等日期逻辑改写为区间：ON b.ts >= CAST(a.ts AS DATE) AND b.ts
• 确保b.ts列上有索引，且类型是DATETIME2或DATETIME（SMALLDATETIME精度不够）
• 如果业务允许，建计算列+索引：ALTER TABLE b ADD ts_date AS CAST(ts AS DATE); CREATE INDEX idx_b_ts_date ON b(ts_date);

跨数据库通用原则：别让函数出现在JOIN条件左侧

所有主流数据库（MySQL/PostgreSQL/SQL Server）在处理JOIN时，对ON子句中带函数的字段都极不友好。真正起作用的是“可下推的谓词”，而不是看起来简洁的函数调用。

容易被忽略的关键点：

• DATE()、CAST(... AS DATE)、CONVERT(DATE, ...)这些操作本身不慢，慢在它们让优化器无法估算基数，进而放弃索引
• 时间窗口预过滤（如BETWEEN或开闭区间）永远比函数截断优先级更高
• 如果JOIN后还要按日期分组统计，建议在JOIN前就用CTE或子查询把日期字段提前算好，避免重复计算