MySQL中IS NULL与大于运算符结合处理datetime时为何失效？

核心原因：优化器简化逻辑与零日期特殊处理的冲突 #

• 你的表中enddate定义为NOT NULL，但在允许零日期的sql_mode下插入了'0000-00-00 00:00:00'，MySQL会把这类零日期当作NULL处理，所以enddate IS NULL能匹配到该行——这是MySQL历史遗留的特殊行为。
• 到了MySQL 8.4，优化器做了更严格的谓词简化：它会根据列的NOT NULL定义，认为enddate IS NULL这个条件永远不可能成立，于是直接把WHERE enddate IS NULL OR enddate > '2025-01-01 00:00:00'简化成只判断enddate > '2025-01-01 00:00:00'。
• 而零日期和'2025-01-01'比较时，结果是不满足（毕竟零日期是极小的无效值），所以简化后的条件匹配不到该行，自然就不返回数据了。

反观MySQL 5.7，优化器没有做这种程度的简化，enddate IS NULL会正常被求值为TRUE，结合OR的布尔逻辑，整个条件结果为TRUE，所以能返回该行。

验证和解决办法 #

• 要验证这个优化器行为，执行以下语句查看执行计划，就能发现8.4已经把IS NULL的条件去掉了：

  EXPLAIN SELECT * FROM t1 WHERE enddate IS NULL OR enddate > '2025-01-01 00:00:00';
  

• 解决方向：
  • 最优方案是彻底替换零日期，将列改为允许NULL，插入NULL代替零日期，从根源避免特殊处理的问题。
  • 若必须保留零日期，显式写出匹配零日期的条件，让优化器无法简化：

    SELECT * FROM t1 WHERE enddate IS NULL OR enddate = '0000-00-00 00:00:00' OR enddate > '2025-01-01 00:00:00';
    

  • 也可以调整优化器参数关闭这种简化，但不推荐，会影响整体查询性能。

内容的提问来源于stack exchange，提问作者dan carter