当数据库中日期以 varchar 类型（如 01-10-2002）存储时，直接使用 Laravel 的 whereMonth() 或 whereYear() 会失效；本文提供两种专业级解决方案：推荐的结构优化方案（改用 DATE 类型）与兼容性兜底方案（MySQL STR_TO_DATE 转换）。
当数据库中日期以 `varchar` 类型（如 `01-10-2002`）存储时，直接使用 laravel 的 `wheremonth()` 或 `whereyear()` 会失效；本文提供两种专业级解决方案：推荐的结构优化方案（改用 `date` 类型）与兼容性兜底方案（mysql `str_to_date` 转换）。
在 Laravel 应用中，若将日期（如 01-10-2002）以字符串形式存入 VARCHAR 字段（例如 start_date），后续按月份或年份查询将无法正常工作——因为 whereMonth('start_date', ...) 依赖底层数据库将字段识别为原生日期类型，而 VARCHAR 字段不支持日期函数解析。
✅ 推荐方案：迁移至标准 DATE 类型（治本之策）
这是最符合数据库设计规范和长期维护性的做法。执行以下步骤：
-
添加新列并迁移数据（确保格式统一为 Y-m-d）：
ALTER TABLE tbl_wallet_detail ADD COLUMN start_date_converted DATE; UPDATE tbl_wallet_detail SET start_date_converted = STR_TO_DATE(start_date, '%d-%m-%Y') WHERE start_date REGEXP '^[0-9]{2}-[0-9]{2}-[0-9]{4}$'; -
修改模型查询逻辑（无需 DB::raw）：
$current_month_balance = tbl_wallet_detail::whereMonth('start_date_converted', now()->month) ->whereYear('start_date_converted', now()->year) ->get(); 最终弃用旧字段：确认无误后，重命名/删除 start_date，并将 start_date_converted 改名为 start_date。
⚠️ 注意：迁移前务必备份数据；若存在非法日期（如 31-02-2023），STR_TO_DATE 将返回 NULL，需清洗后再迁移。
⚙️ 兼容方案：运行时转换（适用于无法修改表结构场景）
若暂无法变更数据库结构，可借助 MySQL 的 STR_TO_DATE() 在查询中动态解析字符串。Laravel 中需配合 DB::raw() 使用：
use Illuminate\Support\Facades\DB;
$current_month_balance = tbl_wallet_detail::whereMonth(
DB::raw("STR_TO_DATE(start_date, '%d-%m-%Y')"),
now()->month
)
->whereYear(
DB::raw("STR_TO_DATE(start_date, '%d-%m-%Y')"),
now()->year
)
->get();✅ 此写法要求原始字符串严格匹配 %d-%m-%Y 格式（如 01-10-2002）。
❌ 若数据中混有 2002-10-01、01/10/2002 或空值，将导致查询结果异常或 SQL 错误。
? 补充建议与最佳实践
- 索引失效风险：STR_TO_DATE() 是计算字段，无法利用 start_date 上的索引，大数据量下性能显著下降。务必在测试环境验证执行计划（EXPLAIN）。
-
Laravel 9+ 更简洁写法：可结合 whereBetween() 提升可读性：
$start = now()->startOfMonth(); $end = now()->endOfMonth(); $balances = tbl_wallet_detail::whereBetween( DB::raw("STR_TO_DATE(start_date, '%d-%m-%Y')"), [$start, $end] )->get(); - 长远规划：在 API 或表单层强制校验输入日期格式，并统一存储为 DATE 类型，从源头杜绝字符串日期问题。
归根结底，存储即契约——数据库字段类型应真实反映业务语义。将日期存为字符串看似灵活，实则埋下查询、排序、时区、索引等多重隐患。优先选择结构优化，临时绕行方案仅作过渡之用。
