SQL查询CURDATE()返回NULL，替换固定日期可正常查询

异常表现 #

• 运行原始查询代码时，SQL中的CURDATE()日期匹配逻辑失效，无法返回目标数据，最终输出仅保留分隔符|，无对应业务字段内容
• 替换验证结果：将查询条件里的CURDATE()改为硬编码固定日期（例如2021-02-08），查询可正常执行，输出符合预期格式的结果，例如Beep Boop | Scheduled | 2021-02-08
• 已完成的前置验证：
  • 业务表post_date字段为标准date类型，并非datetime类型
  • 相同查询语句在SQL Fiddle工具中可正常返回匹配数据
• 复现异常的原始代码：

$sql = $database->get_assoc("SELECT * FROM `table` WHERE `post_date` = CURDATE()");
echo $sql['title'].' | '.$sql['status'].' | '.$sql['post_date'];

核心排查方向 #

• 检查PHP到数据库的会话时区配置：数据库服务的全局时区配置正常，不代表PHP建立的独立连接会话时区和业务存储时区一致。如果会话时区和post_date存储对应的时区存在偏差，CURDATE()计算出的会话当前日期会和表内存储的实际日期错开，导致没有匹配结果
• 检查数据库封装层的SQL处理逻辑：部分自定义的数据库操作封装类，会对传入的SQL字符串做自动转义、关键字拦截，可能把CURDATE()这类内置函数误识别为普通字符串加上引号，导致MySQL无法正常解析执行函数，最终计算出的日期值为NULL
• 核对数据库账号权限：给业务应用配置的数据库账号若做了最小权限加固，可能出现权限配置疏漏，拦截了CURDATE()这类内置函数的执行权限，导致函数调用无法返回正常结果

对应解决方案 #

• 在建立数据库连接后，手动设置当前会话的时区值，确保会话时区和业务日期存储时区统一，可在连接初始化阶段执行类似SET time_zone = '+8:00'的语句，时区偏移值根据业务实际时区调整
• 避免强依赖数据库端的内置日期函数，可在PHP侧计算好当前日期字符串传入查询条件，规避会话时区、权限、封装层拦截带来的异常，修改示例：

$today = date('Y-m-d');
$sql = $database->get_assoc("SELECT * FROM `table` WHERE `post_date` = '$today'");
echo $sql['title'].' | '.$sql['status'].' | '.$sql['post_date'];

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