MySQL查询优化：如何用计算字段筛选相交演唱会并提升性能？

首先，咱们得先搞清楚为什么end_date不能在WHERE里用：SQL的执行顺序是FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY，你在SELECT里定义的别名end_date，在WHERE执行阶段还没生成呢，所以自然没法用。

最优解决方案：把计算逻辑直接移到WHERE子句里 #

既然不能用别名，那咱们直接把end_date的计算逻辑写到WHERE里就行，这样既符合SQL规则，又能利用索引提升性能，完全不用依赖HAVING。

针对你筛选与特定时间点相交的演唱会需求，正确的SQL应该是这样：

SELECT 
    id, 
    duration, 
    start_date, 
    DATE_ADD(start_date, INTERVAL duration MINUTE) AS end_date 
FROM concerts 
WHERE 
    start_date <= '2019-06-08 10:00:00' 
    AND DATE_ADD(start_date, INTERVAL duration MINUTE) >= '2019-06-08 10:00:00';

这个逻辑的本质是判断：演唱会的开始时间不晚于目标时间，且结束时间不早于目标时间——也就是目标时间点落在演唱会的时间段内，完全符合你的需求。

性能优化点：

如果你的start_date字段建了索引，start_date <= 'xxx'这个条件会先通过索引过滤掉大部分不相关的数据，剩下的少量数据再计算end_date是否满足条件，性能会比用HAVING好太多（因为HAVING是在所有行都查询出来之后再过滤，相当于全表扫描）。

关于WHERE和HAVING的联合使用 #

1. 能不能同时用WHERE和HAVING？
   当然可以，但只有在存在GROUP BY分组操作的时候才有意义：

• WHERE用来过滤原始行数据，提前排除不需要的行，减少分组的数据量；
• HAVING用来过滤分组后的聚合结果，比如筛选COUNT(*) > 5的分组。

如果没有GROUP BY，用HAVING其实和WHERE功能类似，但性能会差很多，因为它是在SELECT之后执行，没法利用索引提前过滤。

2. 有没有必要用WHERE OR HAVING？
   完全没必要。所有可以用HAVING实现的非聚合条件，都可以移到WHERE里实现，而且性能更好。只有当条件涉及聚合函数（比如SUM(duration) > 120）时，才必须用HAVING。

替代方案：提前计算并存储end_date #

如果你的演唱会数据不会频繁修改，还可以考虑在concerts表中新增一个end_date字段，在插入或更新数据时自动计算并存储（比如用触发器或者应用层逻辑）。这样查询时直接用end_date字段做条件，性能会达到最优，因为可以给start_date和end_date都建索引，实现更高效的范围查询。

内容的提问来源于stack exchange，提问作者V-K