MySQL DATE_FORMAT转日期为dd/MM/YYYY时create_date未定义排查

• 枚举条件匹配失效：从posts表建表结构可知，category字段为枚举类型，实际存储值为tinh-tuc、su-kien这类英文短码，原查询的WHERE条件写的是p.category = 'Tin Tức'，根本匹配不到有效数据行，空集场景下部分数据库驱动解析列元信息时会抛出误导性的“字段未定义”报错。
• 计算列无别名引发解析异常：原SQL中DATE_FORMAT(p.create_date, '%d/%M/%Y')未设置别名，这类无显式名称的计算列，在老版本mysqlnd扩展中会被解析为空字符串列名，后续代码读取时就会出现create_date字段不存在的错误提示，和真实的列名逻辑产生偏差。
• 日期格式化参数偏差：原语句使用的%M格式符返回的是完整英文月份名称（如January），并非需求要求的两位数字月份，对应两位数字月份的格式符为%m。
• 排序列存在歧义风险：原SQL的ORDER BY id DESC未指定表别名p，在严格SQL模式下容易触发列归属解析失败的问题。

$listNews = "
SELECT 
  p.images,
  p.title,
  p.category,
  DATE_FORMAT(p.create_date, '%d/%m/%Y') AS formatted_create_date
FROM posts p
WHERE p.status = 'Active' 
  AND p.category = 'tin-tuc'
ORDER BY p.id DESC
";
$stmtNews = $sqlCon->prepare($listNews);
$stmtNews->execute();
// 指定返回关联数组，避免索引混合带来的读取偏差
$newsPanel = $stmtNews->fetchAll(PDO::FETCH_ASSOC);
$stmtNews->closeCursor();

• 去掉DATE_FORMAT就能正常查询的核心原因：原查询的WHERE条件因为枚举值不匹配，本身已经处于空集边缘，未设置别名的原生create_date列在返回时可以被驱动正常解析；一旦加入无别名的函数计算列，驱动在合并列元信息时就容易出现解析错位，叠加空集的异常场景，最终抛出create_date未定义的误导性错误。
• 修正后格式化后的日期值，会存储在结果集的formatted_create_date键下，前端渲染直接读取该字段即可得到符合dd/MM/YYYY格式的日期值。

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